Google haalt www en https weg uit adresbalk in Chrome 76

De Chrome-browser toont vanaf de recentste versie geen www of https meer in de adresbalk. Het bedrijf wil daarmee de gebruikersinterface van de browser simpeler maken. Als gebruikers de subdomeinen willen zien, moeten ze daarvoor eerst doorklikken.

De wijzigingen zitten in Chrome 76, de recentste versie van de browser. Daarin zijn subdomeinen als www. niet meer te zien, al blijft de mobiele aankondiging m. wel bestaan. Ook verstopt google https://, maar als een website geen gebruikmaakt van ssl, verschijnt er alsnog een waarschuwing dat de website misschien onveilig is. Gebruikers kunnen het volledige domein nog wel zien als ze op de desktop twee keer in de adresbalk klikken. Op mobiele apparaten hoeft dat maar één keer.

Het is niet de eerste keer dat Google het subdomein verstopt. Dat deed het bedrijf ook al in september vorig jaar in Chrome 69. Daarop kwam echter veel kritiek van gebruikers, waarop Google besloot het ontwerp in te trekken. Ook nu zijn gebruikers niet tevreden, blijkt uit reacties op de changelog waarin de verandering wordt aangekondigd. "Jullie noemen www een speciaal geval, maar het is waardevolle en belangrijke informatie", schrijft een gebruiker.

Google heeft een extensie ontwikkeld waarmee gebruikers alsnog kunnen zien welk subdomein wordt gebruikt.

Reacties (310)

[SideShow]

Heb ik al terug uitgezet via chrome://flags/ en dan zoeken op "hide".
Als webdev wil ik zien waarmee ik bezig ben.

[Smuey]

Precies dit. Leuk voor de consument, minder leuk voor mensen die dit dus wél dagelijks nodig hebben

[dmantione]

Ik wil in twijfel trekken of dit in het belang van de consument is: Je kunt dit vergelijken met het verbergen van bestandsextenties door Windows, allemaal enge drielettercodes waar de consument zogenaamd te dom voor was. Dus konden onverlaten vervolgens virussen versturen met als bestandsnaam leukbrief.txt.exe en hadden consumenten geen idee dat ze programma's opstarten.

Zonder dat ik onmiddelijk misbruik zie, ik denk dat URL's gewoon integraal onderdeel zijn van hoe het internet werkt en dat je niet moet willen proberen de consument iets anders te tonen dan wat er werkelijk op het internet gebeurt, uiteindelijk moet de consument ook de volledige domeinnaam weten.

[sambalbaj]

Eerst wordt consumenten aangeleerd om vooral op httpS te letten in het adres van een site en nou gooit de meest gebruikte browser dat er doodleuk uit.

Nee vertrouw voortaan maar blind op een groen slotje of de browser geeft zelf wel aan als het niet 'veilig' is.

[anandus]

Ik dacht dat Chrome http zonder -s ging blokkeren?

[Tokkes]

Dat wil je niet. Dan breek je de captive portal van veel openbare Wifi punten.

[Anoniem: 498327]

Waarom je het vooral niet wilt: veel sites met echte informatie zijn nog steeds http. Miljoenen zelf gehobbyde sites met informatie over verzameling X, Y en Z. Helaas heeft Google deze sites al vaak naar pagina 3485 verbannen, waardoor er geen hond meer op de sites komt en veel auteurs de handdoek al in de ring hebben gegooid. Ik zou het graag onderzoeken als ik de tijd had, maar mijn onderbuikgevoel zegt dat op internet DOOR DIT BELEID VAN GOOGLE, op dit moment iedere dag meer nuttige informatie verdwijnt dan dat er nieuwe nuttige informatie bijkomt.

[Reactie gewijzigd door Anoniem: 498327 op 23 juli 2024 10:58]

[SeBsZ]

Nee hoor, groene slotjes zijn ook weggehaald. Er komt nu alleen nog duidelijk in beeld als iets NIET veilig is.

[Jannis]

In de huidige release? Hier op macOS zie ik in Chrome nog gewoon het slotje voor de url (net geupdate naar Chrome 76)

[SeBsZ]

Maar geen groene of "secure" meer

[Olaf van der Spek]

Je kunt dit vergelijken

Nee, dat kun je niet.

Een "Niet Veilig" waarschuwing werkt veel beter dan een Veilig indicatie.
Controlelampjes in auto's en vliegtuigen werken ook zo: uit als er niks aan de hand is, aan als er wel wat is.
Een lampje dat uit is, valt namelijk niet op.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 10:58]

[freaq]

Behalve dat je dan dus niet weet of het lampje werkt.

Lampje groen veilig
Lampje rood probleem
Lampje uit, mogelijk lampje kapot mogelijk meer aan de hand...

[Olaf van der Spek]

Behalve dat je dan dus niet weet of het lampje werkt.

Daarom gaan de lampjes aan voor het starten..

Lampje groen veilig
Lampje rood probleem
Lampje uit, mogelijk lampje kapot mogelijk meer aan de hand...

Groen en rood zouden aparte lampjes / leds zijn dus dat zegt nog steeds niks.
Bovendien zijn leds aardig betrouwbaar.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 10:58]

[freaq]

Eh ja als het groene lampje kapot is en er geen gele of rode brandt weet je dus dat er iets aan de hand is.
Wat dat is, is de vraag maar je weet iig meer dan als get lampje altijd uit is tenzij er een probleem is, maar je niet weet of de lamp het doet.

[Olaf van der Spek]

Probleem is dat een rood lampje tussen alle groene lampjes nog steeds niet opvalt.

[jeroen_loeffen]

Een defect lampje is ook uit, lampjes die aan staan heben zeker toegevoegde waarde

[107mb]

een defect lampje op een scherm?

[Ectra]

Kan gezien als een onvelige sites die toch word weergegeven als "veilige site"

[Matthijs Hoekstra]

dat veilig, niet veilig is sowieso al stom en heeft niets met de veiligheid van de website te maken maar alleen met de verbinding naar die site.

[Anoniem: 498327]

Precies, de verbinding met Google is veilig, maar Google zelf niet.

[i-chat]

Ik ben het er mee eens dat veilig en/of niet veilig de lading voor leken slecht dekt, maar toch is het belangrijk om vast te stellen hoe het met de verbinding zit, ben je wel met de juiste server verbonden, zijn er geen meeluisteraars, of word ik gewoon gefished.

tegelijkertijd is het huidige systeem natuurlijk ook helemaal bagger. vage bedrijfjes in verre landen kunnen vrij gemakkelijk een site als tatwe.com registeren en daar certificaatjes mee uitgeven voor microsoft.com

het feit dat je browser geen dns-validatie doet op het cert in de vorm van een daarvoor bestemd dns-record, dat dns-boeren geen name-checking doen om te kijken of er geen sprake is van typesquatting oid maakt van het internet een inherrent onveilige plaats. daar heeft google weinig mee van doen.

offtopic:
Stellen ddat google niet dan per definitie onveilig is en dan ook nog eens +2 krijgen laat weer eens duidelijk zien hoe het met de tweakers comunity is gesteld. hoeveel er ge-meningmod wordt op een bericht zonder bronnen, of nadere uitleg. die +2 in plaats van de verdiende 0 (of zelfs -1?) is een schande voor tweakers.net als geloofwaardig platform

Deze reactie is natuurlijk ook een beetje off-topic maar ach als dat +2 krijgt dan mag dit ook wel eens een +3 vooral omdat klagen op het 'relevante' forumdraadje nooit het gewenste resultaat zal hebben: namelijk dat mensen er mee stoppen.

[jenstokvis89]

Ja dit is een prefecte vergelijking.

[Sebazzz]

Google wilt dat de zoekmachine is waar je internet begint. Waarom zou je nog urls moeten gebruiken. Allemaal zo technisch.

[Anoniem: 498327]

Helaas wordt dit meer en meer Amazon, behalve in NL. Amazon wordt steeds vaker als eerste zoekmachine gebruikt, ik snap dat wel, Amazon is duidelijk op verkoop gericht. Google probeert antwoorden te geven, maar is in businessmodel op verkopen gericht: Resultaat 80% zoekresultaten is verkoopgerelateerd, dus jaag je klanten naar Amazon waar het gewoon zo klaar als een klontje is. Voor echt zoeken is er niks meer.

[Nickname55]

Als ik Windows opnieuw installeer, is dat 1 van eerste dingen die ik instel: bestandsextensies weergeven.

[Ayporos]

waarom stoppen bij www en https, waarom niet gewoon ALLE (sub)domeinen verbergen en gewoon 'com' of 'net' in de adresbalk laten zien...

Of nog beter... gewoon GEEN adresbalk!

Serieus, die shit is gewoon onderdeel van het adres en ik vind het een ZEER kwalijke zaak dat google gaat lopen beslissen voor ons wat we wel en niet hoeven te weten..
Da's net zoiets als een kaart die alleen huisnummers laat zien want de straatnamen vind de kaartmaker dat die niet belangrijk zijn voor jou.

écht, maar dan ook écht belachelijk!

[BruT@LysT]

Is het serieus zo'n groot probleem? Ik heb er als front-end dev echt geen probleem mee.. kwalijke zaak.. omg
Het is toch voor een hoop 'tweakerstjes' vaak wel erg lastig om je te verplaatsen in de gewone gebruiker. Waarom zouden WIJ ons hier nou druk om moeten maken.

[svenslootweg]

Ja, het is wel degelijk een groot probleem, juist voor gewone gebruikers.

In tegenstelling tot een web developer, kun je van een gewone gebruiker niet verwachten dat ze precies begrijpen hoe bijvoorbeeld een browser of een URL werkt. Bij dergelijke systemen - waar de gebruiker de werking niet snapt, maar er wel mee moet werken - is de #1 ontwerpregel dat het zich consistent moet gedragen, zodat de gebruiker met een paar simpele vuistregels het systeem kan begrijpen.

In het geval van URLs is die consistente regel "wanneer je aan iemand het ding geeft dat je in de adresbalk ziet, en zij typen het in, dan krijgen ze dezelfde pagina". Deze regel gaat niet meer op zodra je 'www.' uit een URL verwijdert; immers kunnen www.example.com en example.com naar twee totaal verschillende servers wijzen (en is dit in de praktijk ook regelmatig het geval).

Zo creeer je dus een situatie waar normale gebruikers extra regels moeten gaan onthouden en communiceren naar anderen; er is een edge case toegevoegd die ervoor zorgt dat de voorheen werkende vuistregel niet meer werkt. Bovendien schaadt dit het algemene vertrouwen in het systeem, omdat het ineens vreemde dingen lijkt te gaan doen ("waarom werkt het niet meer als ik deze URL aan iemand anders geef?").

Even heel plat gezegd: Google is hard bezig om de fundamentele onderdelen van het open web te slopen, ten bate van hun eigen gesloten ecosysteem. Dit is incident nummer zoveel, en in dit geval raakt het de integriteit en reproducibiliteit die gebruikers verwachten van een URL. Dat zal er uiteindelijk toe leiden dat mensen de betrouwbaarheid van URLs gaan wantrouwen.

Of dit een bewuste zet is of dat het ze gewoon niet boeit, daar kan ik niets over zeggen; maar het is wel weer een opvallend datapunt in een langdurige trend. En dat deze wijziging alsnog doorgevoerd wordt, ondanks dat bovenstaande kritiek rechtstreeks aan de voordeur van Chrome-ontwikkelaars is afgeleverd (en ze dus sowieso van het probleem op de hoogte zijn), zegt m.i. een hoop over de intenties.

[Olaf van der Spek]

Deze regel gaat niet meer op zodra je 'www.' uit een URL verwijdert; immers kunnen www.example.com en example.com naar twee totaal verschillende servers wijzen (en is dit in de praktijk ook regelmatig het geval).

Verschillende servers / sites voor met en zonder www. is toch gewoon een slechte keuze?

[svenslootweg]

Ik ben het helemaal met je eens dat het (in vrijwel ieder geval) inderdaad een slechte keuze is, en het is vaak ook een indicatie dat een beheerder niet goed snapt hoe DNS werkt.

Dat neemt echter niet weg dat het weldegelijk (veel) voorkomt, en dus een praktisch bezwaar oplevert tegen het verbergen van de www-prefix in browsers, want voor de eindgebruiker maakt het niet uit wie het precies heeft gesloopt; zij ervaren enkel dat URLs niet meer goed werken.

[McBacon]

Om maar even een voorbeeldje te noemen: (self-hosted) mailservers, aangezien mailtjes als spam gemarkeerd of zelfs geheel gedropped kunnen worden als je reverse DNS niet in orde is.

In mijn geval heb ik een losse mailserver en staan websites over verschillende andere servers, een toch wel veel voorkomende setup. Het domein die de mailserver in zijn EHLO gebruikt heeft (uiteraard) een A record en bij de serverprovider maak ik daar een matchend PTR record voor aan. Voor de website heb ik dus een www subdomain met een ander IP, plus een @ record met hetzelfde adres voor de volledigheid. Als je de non-www variant gebruikt is het uiteindelijk afhankelijk van de DNS client welk IP die als eerst probeert, je kan dan dus op de verkeerde server uit komen. If so, dan krijg je een mooie error page i.p.v. de site die je wilde. Ik was het zelf een keer glad vergeten en uiteindelijk zag ik aan de URL dat ik probably op de verkeerde server was uit gekomen. Bless Firefox. =]

Nu denk je waarschijnlijk, maar dan gebruik je toch mail.domain.tld voor je rDNS? Het is alleen zo dat ik nog een paar andere services via de mailserver heb draaien die uiteindelijk ook gecheckt worden op rDNS, die zouden dan ook mail.dom.tld rapporteren i.p.v. gewoon dom.tld. En meerdere PTR records is (iirc) volgens de relevante RFC geen "expected behaviour".

[Olaf van der Spek]

Het domein die de mailserver in zijn EHLO gebruikt heeft (uiteraard) een A record en bij de serverprovider maak ik daar een matchend PTR record voor aan.

Dat hoeft toch niet te matchen?
Een mail server kan meerdere maildomeinen afhandelen en je hebt toch maar één PTR record.

Een A record is ook niet per se nodig, MX zou voldoende moeten zijn dacht ik.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 10:58]

[Blinkin]

Zolang het doel vanhhet MX record wat ingesteld is naar een in de DNS bestaand (sub)domein wijst moet dat werken ja.

[Reactie gewijzigd door Blinkin op 23 juli 2024 10:58]

[Olaf van der Spek]

Een MX record bevat een IP adres en geen naam, toch?

[Blinkin]

Nee een MX record wijst altijd naar een host wat vaak een subdomein is. Naar een ip verwijzen heb ik zelf nog nooit werkend gezien (misschien dat het wel kan). Dit is ook geheel volgens de specificaties van het RFC 1035.

Een van de reden is het gebruik van meerdere ip's wat niet gaat in 1 MX record. Al heb je natuurlijk ook het gebruik van meerdere MX records met verschillende prioriteiten.

[McBacon]

In mijn ervaring checken ontvangende mailservers de naam uit de EHLO op (r)DNS. Als die geen bestaand A record heeft failed de check sowieso al en de PTR van het IP moet vervolgens resolven naar dezelfde FQDN. Daarnaast moet je bij sommige serverproviders eerst een correct A record hebben voordat ze je toestaan om een PTR record te maken.

MX is inderdaad voldoende om de mail van al je domains uit te laten komen bij die ene mailserver, maar wordt verder niet gebruikt in de reverse DNS check afaik.

Vergeet ook niet dat de EHLO altijd dezelfde domeinnaam gebruikt, deze staat los van de domeinen die de server afhandelt (bijv. virtual_mailbox_domains in Postfix). Het is dus niet afhankelijk van het domein waar je naartoe mailt, wat je volgens mij wel impliceert met "en je hebt toch maar één PTR record".

[sdk1985]

Tegenwoordig heb je een MX, spf, dkim en rdns record nodig. In ieder geval indien je wil voorkomen dat je mail geblockholed wordt door partijen als microsoft.

[Reactie gewijzigd door sdk1985 op 23 juli 2024 10:58]

[Olaf van der Spek]

URLs overtypen is sowieso foutgevoelig en met copy/pasten heb je het www. probleem ook niet.

En meest wordt er gewoon een zoekterm getypt, geen URL.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 10:58]

[svenslootweg]

Wederom: het klopt dat URLs overtypen foutgevoelig is, maar mensen doen het wel. Goede software bouw je op de realiteit, niet op een ideaalbeeld.

[Olaf van der Spek]

Realiteit is ook dat mensen soms de www. ook wel of niet overtypen. De enige lange termijn oplossing is dan zorgen dat het geen verschil maakt.

[ejabberd]

Inderdaad. Om die reden heb ik al zeer lang een rewrite op al mijn websites: als iemand 'www.<website>' intikt, dan wordt dat zichtbaar aangepast naar <website>.

[Tokkes]

en het is vaak ook een indicatie dat een beheerder niet goed snapt hoe DNS werkt.

Hoe dan?
Ten eerste: je vHost kan perfect ingesteld staan dat die enkel op www.* luistert.
Ten tweede: aan bovenstaande kan de DNS beheerder meestal weinig doen.
Ten derde: mijn domein.xyz heeft mail.domein.xyz, dit.domein.xyz, en ga zo nog maar door. Ik heb nu inderdaad geen grote publieke portal ofzo die ik beheer, maar om dan inderdaad 'maar' aan te nemen dat www.domein.xyz hetzelfde is als domein.xyz, de persoon die DAT doet begrijpt DNS niet helemaal. Dit kan namelijk een bewuste keuze zijn.

[divvid]

Hoezo slechte keuze?

https://[api|dev|m|etc...].example.com kan ook naar een andere server wijzen. Ook maar weghalen? Het is juist aan diegene die het DNS beheert om te bepalen baar welke server iets wijst.

Zowel als consument als dev wil ik gewoon het hele adres zien.

Het is al irritant genoeg dat http sites niet meer te laden zijn als je één keer per ongeluk https hebt ingegeven (firefox bv, chrome gebruik ik niet) zonder hem uit de cache te halen. Heel handig voor dev (not)

[Raem]

Ik vraag me af wat er gaat gebeuren wanneer iemand www voor een subdomein zet. Ik zie namelijk nog steeds regelmatig dat mensen standaard www gebruiker wanneer ik mondeling een domeinnaam doorgeef.

Bijvoorbeeld gathering.tweakers.net wordt dan in de adresbalk geschreven als www.gathering.tweakers.net/.
Die laatste geeft een ssl-error, maar door deze aanpassing ziet de gebruiker dan dus niet meer dat hij www. ervoor heeft getypt. Dat wordt aan de telefoon dan een leuk gesprek.

"Je bent naar gathering.tweakers.net gegaan?"
*Gebruiker kijkt naar adresbalk* - "Ja, dat staat er'.

[sdk1985]

Dat ligt meer aan tweakers dan aan de gebruiker die er nog een keer www bij zet. Als jij op een directadmin hosting pakket een subdomein toevoegt dan wordt het subdomein én de variant met www ervoor standaard aan de DNS records toegevoegd. Daarna is het natuurlijk handig als je de niet preferente variant laat doorverwijzen naar de preferente variant...Dat is wat tweakers hier blijkbaar is vergeten.

[batjes]

Ach, we zijn als Tweakers zelf mede verantwoordelijk voor de dominantie van Google en de huidige situatie waarbij Chrome zich in een IE6 positie bevind.

Google heeft met onze hulp de browser markt compleet over genomen. En de afgelopen jaren begin je te zien hoe eng dit eigenlijk wel niet is. Gezeik om die adblockers, het verneuken van het web naar "hun visie". Het vendor locken van de ondertussen hordes websites die beter werken in Chrome dan andere browsers, waarvan Google's eigen sites een prachtig voorbeeld zijn. Gebruik youtube.com in Edge en Chrome en je zult duidelijk zien welke ervaring een stuk beter is. Terwijl op pornhub de ervaring wel identiek is. Fuck you Google.

Ze zijn een heel stuk achterlijker bezig dan wat Microsoft met IE6 heeft uitgevreten. Dit is echt van een hele andere orde. Microsoft zag in de jaren 90 geen toekomst in het WWW en heeft hun IE dominantie niet lopen monetizen, de dominantie was meer bijzaak door Microsoft's achterlijke gedrag betrekkende Windows. Waar ze ook hard en terecht voor afgestraft zijn.

En nu verrast zijn dat we 20 jaar terug de tijd ingeschoten zijn en nog verder van huis zijn. Niet om je verhaal verder af te vallen, zeker goede punten. Maar we doen hier op Tweakers nu alsof onze neus bloed. Wij, de nerds van het internet. Zijn hier verantwoordelijk voor geweest.

Nu Microsoft de browser markt uit stapt, oooh dit gaat zo ontzettend fout. Mozilla gaat het niet alleen trekken tegenover Google, vooral niet zolang ze afhankelijk zijn van Google voor het voortbestaan van Mozilla. Google heeft Mozilla echt kei en keihard in de rug gestoken.

[Reactie gewijzigd door batjes op 23 juli 2024 10:58]

[BruT@LysT]

Ja ik geloof er echt geen zak van dat dit voor de gewone gebruiker een probleem vormt. Volgens mij zie je gewoon beren op de weg. Soms helpt het echt enorm om gewoon onwetend te zijn. Laat het in de praktijk maar uitwijzen dat het een probleem vormt. Ik wacht af.

[WoutervOorschot]

De site van je bank verteld je te controleren of de URL klopt, in chrome klopt die niet meer met wat de bank zegt. Wie vertrouw je dan?

[yeep]

Als er in mijn adres balk geen ING.NL staat weet ik dan toch dat het fout is? Hoeveel maakt het uit dat er wel of geen WWW voor staat?

[Olaf van der Spek]

https://ing.nl.particulieren.info/index.php en menigeen zal niet doorhebben dat er iets mis is.

Domeinen van rechts-naar-links laten lopen is eigenlijk gewoon een grote fout geweest.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 03:58]

[efari]

Als Chrome dus binnenkort enkel het domein particulieren.info gaat tonen in de adresbalk, dan is het toch nog duidelijker?

[Ultimus XI]

Maar is dat (https://ing.nl.particulieren.info/index.php) niet nu ook al een probleem als je voor dat sub domein nog een extra subdomein 'www' voor zet of wordt dat niet toegestaan?

Anders zie ik namelijk geen verschil met de huidige situatie.

[Reactie gewijzigd door Ultimus XI op 23 juli 2024 06:33]

[helioda]

Inderdaad, getallen beginnen ook met de meest significante digits eerst.
Bij een normale klok vind ik het ook altijd een gemiste kans om de meest significante wijzer klein te laten zijn. Wat mij betreft zou dat ook andersom moeten zijn.

Maar uiteindelijk begrijp ik wel waarom dat zou gedaan is. Als je al weet wat het uur is, dan is het makkelijker om op grote afstand de lange wijzer beter te kunnen zien. Zo is het ook met url's. Als je al WEET op welke website je zit, dan is het makkelijker om de specifieke pagina eerst te zien, zodat je meteen weet op welke subpagina je zit.

[morphje]

slecht voorbeeld. Het certificaat matched niet met deze site. Browser waarschuwt netjes

(ja, ik klik gewoon )

[bvanaerde]

Nog een geluk dat intussen zowat elke browser je erop attent maakt dat er iets mis is met het certificaat, en je de toegang dus gaat blokkeren

[Olaf van der Spek]

Waarom zou er iets mis moeten zijn met het certificaat?

Het is voor ing.nl.particulieren.info geen enkel probleem om een geldig certificaat (voor ing.nl.particulieren.info) te hebben.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 10:58]

[Tourmaline]

Ik zie wel beren...

stel iemand typt http in in plaats van https dan krijg je een foutmelding maar je kunt niet zien waarom. Je ziet dat immers niet meer in je adresbalk...Wat heeft het voor zin om dat weg te laten....

[yeep]

Dan heb je sowieso een slechte website als deze geen HSTS ondersteund, maar dat is een andere discussie :-)

[Tweekzor]

Om HSTS te activeren moet je eerst al een keer de HTTPS versie van de website bezocht hebben (op een handvol pre-loaded HSTS sites van je browser na). Wat veel sites wel doen is HTTP verkeer standaard redirecten naar een HTTPS versie. Of dit je direct een "slechte website" maakt durf ik niet direct uit te spreken.

[(TWIJG)]

Zeker al websites gezien die bij https doorverwijzen naar een compleet andere site.
Ik heb toen de websitebouwer gecontacteerd, blijkbaar verwijzen alle ongeldige verzoeken naar zijn hoofdsite en dus ook https bij sommige sites (intussen heeft hij het overigens opgelost).

[WillySis]

Ik ben bang dat de gewone gebruiker het weglaten van http(s) en www wel gemakkelijk vindt. Het adres wordt zo wel wat korter. Je hoeft de weggelaten delen ook niet in te tikken als je naar een website gaat. In gebruikswaarde lijken de weg te laten onderdelen voor veel mensen ook nutteloos.
Wie serieus bezig is kijkt wel naar deze onderdelen om te kijken of de site wel helemaal koosjer is.

[bvanaerde]

www. is deprecated
Om eventjes te quoten:

In order to answer this question, we must first recall the definition of WWW:

World Wide Web:
n. Abbr. WWW
1) The complete set of documents residing on all Internet servers that use the HTTP protocol, accessible to users via a simple point-and-click system.
2) n : a collection of internet sites that offer text and graphics and sound and animation resources through the hypertext transfer protocol.

By default, all popular Web browsers assume the HTTP protocol. In doing so, the software prepends the 'http://' onto the requested URL and automatically connect to the HTTP server on port 80. Why then do many servers require their websites to communicate through the www subdomain? Mail servers do not require you to send emails to [e-mail]. Likewise, web servers should allow access to their pages though the main domain unless a particular subdomain is required.

Succinctly, use of the www subdomain is redundant and time consuming to communicate. The internet, media, and society are all better off without it.

Aangezien dat het www subdomein standaard gebruikt wordt voor als je geen subdomein nodig hebt, is het in de meeste gevallen dus overbodig. Wat mij betreft is het dus geen probleem om het www-gedeelte te verbergen.

De site mag wel eens iets doen aan het ontbreken van een SSL certificaat

[svenslootweg]

"Deprecation" omvat het als verouderd markeren en uiteindelijk verwijderen van functionaliteit door een maintainer. De www prefix is dus helemaal niet deprecated, ongeacht wat een willekeurige website van een derde partij daarover zegt.

Het is ook totaal irrelevant; het probleem is hier van praktische aard (er zijn simpelweg nog een hoop sites waar de www en non-www records niet matchen), en wat mensen graag zouden zien doet er niets aan af dat deze wijziging in Chrome in de huidige situatie een onbetrouwbaar systeem oplevert.

[bvanaerde]

er zijn simpelweg nog een hoop sites waar de www en non-www records niet matchen

Dat was dan ook meteen de insteek van deze site: beheerders erop attent maken dat ze hun sites tenminste bereikbaar maken zowel met als zonder www subdomein, al was het maar door een simpele redirect toe te voegen.

Al vraag ik me wel af of er écht zoveel sites zijn waar dat er effectief een andere site wordt getoond als je het www subdomein wel of niet gebruikt. Dat er nog een hoop sites gewoonweg niet zullen werken bij het ontbreken/toevoegen van het www subdomein, daar ben ik wel mee akkoord.

Maar ik snap uiteraard dat je vanuit het standpunt van de eindgebruiker het zo duidelijk mogelijk wil houden.

[Tokkes]

Mail servers do not require you to send emails to [e-mail]. Likewise, web servers should allow access to their pages though the main domain unless a particular subdomain is required.

HOOOOW daar even.
Mail servers sturen wel degelijk naar '[e-mail]' - daar dient het MX record voor in DNS. Jijzelf stuurt de mail naar [e-mail], de MTA gaat dan uitzoeken waar dat mailtje naartoe moet.
Moeten we dan DNS gaan uitbreinden en een 'WWW' record toevoegen?! Lijkt mij de slechtste oplossing nog niet... Dan kan je browsers standaard naar de website op het WWW record laten gaan (dat kan dan gewoon www. zijn wat een A record is voor de webserver) en het 'gewone' A record kan naar iets anders (of niets) wijzen. Om je browser dan het A record te laten opzoeken, doe je '.domain.xyz' (dus met . als prefix)

[Reactie gewijzigd door Tokkes op 23 juli 2024 10:58]

[bvanaerde]

Mail servers do not require you to send emails to [e-mail]

Hiermee wil 'ie zeggen: je hoeft niet speciaal een subdomein aan te maken speciaal voor de mail. Je kan dus perfect [e-mail] gebruiken ipv [e-mail]. Zoals je zelf zegt, daar dient het MX record voor.

[T-men]

Helemaal eens met je post, toch één kanttekening:
Ik vraag me af hoeveel gebruikers wérkelijk opletten met wat ze in de balk zien ?

• Meestal is het klikken op een link en zie je de URL sowieso pas achteraf in de URL-balk (in de statusbalk is de URL vooraf wél gewoon te zien)
• En wanner je moet typen... ik vraag me af of een gebruiker van het nivo van mijn mijn moeder überhaupt wel wéét dat er een verschil is. Laat staan dat ze er op moeten letten.

Hoewel ik het niet eens ben met de wijziging van Google denk ik dat het in de praktijk niet veel verschil zal maken.

[Rabb]

Helemaal niemand typt http(s) noch www in de browser. De browser veranderd dit voor de gebruiker. If anything, Chrome word nu consistenter doordat de url niet word aangepast.

[Andy Wachelder]

Zeker de reactie van dmantione boven ergens gemist? Ik heb als werkplekbeheerder dagelijks met "de gewone gebruiker" te maken en veel kijken inderdaad naar vreemde bestandsextensies om te beoordelen of iets veilig te openen is. Maar ja, je bent dan ook vertegenwoordiger van een beroepsgroep die, weet ik uit ervaring, een nogal lage dunk heeft van "de gewone gebruiker". Of dat, of je bent gewoon heel slecht in sarcasme c.q. "tongue in cheek"...

[telenut]

nee, dit is gewoon niet voor elk huisnummer op de kaart de straat ook nog eens zetten.
Of voor de straatnaam telkens het land nog eens zetten...

gewoon de overbodige info weg laten maakt het gebruiksvriendelijker
dan heb je ook niet van die mensen die nog overal manueel https://www gaan typen (doorgaans mensen die niet snel typen ook...)

[t-force]

Google mag beslissen hoe Chrome werkt.
Als je dat niet fijn vindt, dan Chrome eraf en bijv. Firefox of Edge gebruiken.
Sowieso is het te verwachten dat Google dingen aan Chrome aanpast die in hun voordeel zijn.

[CAPSLOCK2000]

Of nog beter... gewoon GEEN adresbalk!

Ik denk echt dat we daar heen gaan. Het zou geweldig zijn voor (zoekmachines als) Google. Als er geen adresbalk is moeten mensen op een andere manier op de juiste site zien te komen. De meest voor de hand liggende manier is om te zoeken naar de site die ze nodig hebben. Zo werkt het in praktijk toch al voor veel mensen. Die tikken niet 'www.mijnorganisatie.com' in maar gewoon 'mijnorganisatie' en ze vertrouwen er op dat hun browser naar een zoekmachine gaat om de juiste site te vinden.

Dat zou de positie van zoekmachines als wegwijzers van internet nog verder versterken. Daarbij wordt het extra aantrekkelijk om een zoekmachine te betalen om jouw website als eerste te noemen.

[Ayporos]

Ja en dát is dus nou precies waar ik bang voor ben.

t-force kan wel zeggen 'ja dan stap je toch over' maar dat is niet echt een correcte uitspraak.
Dat is net zo nutteloos als zeggen "ja als Ziggo je niet bevalt stap je toch over op een andere kabelboer."...
komt op hetzelfde neer.

[t-force]

Je hebt compleet gelijk.

Genuanceerd zou ik zeggen dat Google een te grote vinger in de (internet) pap heeft. En dat de meeste Chrome gebruikers als makke schapen Chrome installeren omdat het de 'beste' browser is. Compleet niet bewust van het feit dat ze zo Google nog meer macht geven.

Ik geef al heel lang aan dat ik bewust ben van de macht van de grote internet giganten die dus eigenlijk bepalen wat internet is en ook hoe we er gebruik van maken.
Helaas geld hier ook de macht van de getallen en is het dat dus de 99% schapen die alles wel leuk/handig of wat ever vinden die dus die macht bevestigingen.
De 1% die wel nadenkt over alle gevolgen hebben feitelijk niet veel in te brengen.

Wat mij betreft stoppen we meteen met het gebruik van Google als zoekmachine en Chrome als browser.

[Ayporos]

Mijn default browser thuis en op het werk is Firefox, en dat is al JAREN zo.

Ik heb een chrome install voor websites die érg moeilijk doen/niet laden met adblock/ghosterly en welke ik toch maar 1x bezoek of zo (dus vind ik niet de moeite om ze te whitelisten).

Google heeft in der daad een te grote vinger in de pap.. en het feit dat ze op politieke (links leunende, pro-corporate (hoe tegenstrijdig dat ook klinkt)) censuur en bias toepassen als bedrijf en op bijv. Youtube geeft mij daadwerkelijk rillingen.

[Fly-guy]

Dan zet je het weer aan in de flags, die zijn er niet voor niets.
Zo is iedereen toch tevreden?

[xoniq]

Had ook gewoon een vinkje kunnen zijn voor instellingen, is toch is toegankelijker voor de gewone consument.

[MSalters]

Mar die gewone consument heeft het vlaggetje helemaal niet nodig - dat is nu juist het punt. Het vlaggetje is e voor de webdev's, en die kunnen het wel vinden.

[xoniq]

Waarom zou een gewone consument het niet nodig hebben? Wat voor moeite is het om een vinkje te maken voor de consument die het wél nuttig vind?

[eborn]

Als je naar de hoeveelheid flags kijkt, snap je dat ze daae niet overal een vinkje van kunnen maken. Dan krijg je een UI waar niemand meer iets van snapt.

De gemiddelde consument snapt het verschil tussen een zoekbalk en de url balk toch niet. Nu is dat tegenwoordig vaak hetzelfde maar vroeger typte men doodleuk de URL in Google in.

[mac1987]

Wat is er mis met een onderscheid in 'standard' en 'advanced' settings ?

[biteMark]

Als je de gemiddelde gebruiker zo gemakkelijk met geavanceerde instellingen laat spelen, dan geef je ze heel gemakkelijk de kans om van alles te verprutsen waarna ze op fora gaan zeuren wat een ***browser het wel niet is. De mensen die dit soort instellingen zoeken weten de flags, al dan niet na een beetje Googlen, wel te vinden.

[Chuk]

'n beetje googlen, en dat is dan weer goed voor de zoekmachine. Zeer slimme zet van Google eigenlijk...

[Ultimus XI]

Alles wat onder 'advanced settings' staat moet in Chrome zelf (in alle talen) duidelijk zijn voor de gebruiker en onderhouden worden. Een flag kunnen ze met minder af doen. Minder onderhoud = goedkoper.

[Drogo]

Nog minder moeite voor de gewone consument is helemaal nergens op hoeven te klikken om deze verbeterde adresbalk te krijgen.

[tom.cx]

Safari heeft dit wel. Alleen jammer dat je het op iPadOS en iOS niet hebt.

[Rabb]

De gewone consument duikt nooit de instellingen in

[Tourmaline]

Nee, die vraagt iemand anders om het te fixen....

[Rabb]

Zoiets als dit niet. Valt niks te fixen voor ze

[Tourmaline]

Schijnbaar wel met een flag...

[Rabb]

Ik bedoel dat er voor de consument niks kapot is. Maargoed, wie weet word het de volgende update toegevoegd aan het settings menu. Best of both worlds

[Andy Wachelder]

Doe me een lol en definieer hier "de gewone consument" eens... Of stop anders met verwijzingen naar die fictieve persoon.

[Smuey]

Het punt is dat het gewoon een bullshit-move is. Waarom moet die URL sowieso verborgen worden? Ik heb er letterlijk nog nooit iemand over gehoord dat ze Chrome (of welke andere browser dan ook!) niet gebruiksvriendelijk vinden omdat ze de volledige URL kunnen zien. Waarom zou je dan juist DAT aanpakken? Ga dan liever wat doen aan de verspilling van gebruikt geheugen ofzo, wat dus wél een reëel issue is.

[efari]

Ik kijk even naar boven naar de adresbalk van iOS safari. Daar is dat al een hele tijd het geval.

Ik zie voor doorsnee gebruikers geen minpunt

[Smuey]

Dus omdat Apple dat op een telefoon doet, moet Google het ook maar doen op alles inclusief desktop, dat is serieus je antwoord? Het is een niet-bestaand issue dat nu wordt 'opgelost'. 'Fijn' dat het voor die doorsnee gebruikers geen probleem gaat zijn, maar ik ben geen doorsnee gebruiker en als webdeveloper ben er niet bepaald blij mee.

Het is gewoon dikke, dikke onzin. Als ik twijfel aan de authenticiteit van een website, is een blik op de volledige URL voldoende om die twijfel te bevestigen of ontkrachten. Als je die dan niet meer snel kan zien, maak je daarmee de kans op misbruik groter. Zoals al eerder aangegeven, als je subdomeinen gaat verbergen, zie je dus niet meer of je op www., portal. of iets anders zit. Lekker, als je straks inloggegevens plaatst op een hijacked subdomein dat er exact hetzelfde uit ziet als het hoofddomein en door deze blamage ook nog eens niet zichtbaar is als een mogelijk verkeerd subdomein...

[efari]

zoals eerder aangehaald: jij als webdeveloper kan gewoon de flag aanzetten zodat je terug alles ziet...
verder: als een website een hijacked subdomein heeft, is inloggen op dat subdomein sowieso fataal (en is de website sowieso in de fout) of het nu per ongeluk gebeurd of niet.
daarbij let de doorsnee gebruiker daar toch niet op, op welk subdomein hij aanmeldt

[Reactie gewijzigd door efari op 23 juli 2024 10:58]

[SOTD]

Dat is iets fixen wat Google kapot maakt. En tig mensen zullen dit niet doen of kunnen en een keer bedrogen uitkomen. Het klopt dat een deel van de mensen hier niet eens eropletten maar die andere deel die juist keer op keer te horen heeft gekregen GOED naar de url te kijken moeten nu leren dat het anders uitziet en dat ze ergens op moeten klikken om te zien dat ze goed/veilig zitten.

Ik vind het heel gek dat dat stukje voortaan verborgen gaat worden. Moet dit onze levens vereenvoudigen? Besparen we nu seconden of zo? Gaan er iets minder bits via het internet heen en weer?

[Reactie gewijzigd door SOTD op 23 juli 2024 10:58]

[analog_]

Nee, dit levert extra pixels op voor Google Ads op te tonen, hahaa

[darknessblade]

ik heb zelf als enduser ook een hekel aan die simplified URL's. liever de http://ipsumlorem,cc,co,uk,com

dan "ipsumlorem"

[sjettepetJR.]

mee eens, ik vindt dat je gewoon moet kunnen zien waar je je bevindt.

op mobiele apparaten met kleinere schermen is er een valide reden om dingen weg te laten, namelijk de gelimiteerde ruimte. maar op desktops is dit geen enkel probleem. er zitten geen voordelen aan het weglaten van de informatie.

[darknessblade]

vooral niet voor de digibeet die denkt dat

''scam,scam,scamsite'' [url]
nu,nl [titel]
maar eigenlijk deze wilde:
nu,nl [URL]
nu,nl [titel]

[Nickvdwaal]

Als je dit dagelijks nodig hebt dan kan je van jezelf toch al zeggen of het http of https is?

[Xtreem1988]

Welke precies selecteren, just to be sure... Thnx

[Maarten]

Omnibox UI Hide Steady-State URL Trivial Subdomains naar 'Disabled' zetten

[Reactie gewijzigd door Maarten op 23 juli 2024 10:58]

[rc_enzo]

Of, door middel van een URL: chrome://flags/#omnibox-ui-hide-steady-state-url-trivial-subdomains

[GeroldM]

Een flag die in een volgende versie van Chrome word genegeerd. Geweldige oplossing....

Leuk dat dit nog werkt in deze versie van Chrome, maar vertrouw er niet op.

Niks ten nadele van je post, Google gedraagt zich met deze filosofie als een stelletje e.kels en daar helpt geen enkele goed bedoelde opmerking tegen.

[Z___Z]

Thanks, het verdwijnen van de een deel van de URL bij het weergeven vind ik niet eens zo erg, maar zodra je in edit mode gaat wil ik wel graag alles zien. In pre-76 build zag je geen http(s), maar als je het url ging kopieren, kopieerde je wel het protocol mee.

[michiel_]

Net getest en bij het kopiëren gaat het protocol gewoon mee. Als je dubbelklikt, zie je gewoon alles.

[memphis]

Als dat gebeurd is het niet zo'n ramp, het zou een grote ramp zijn dat als je bij het kopieren ook echt krijgt wat er staat, kan je alsnog de rest typen in de hoop dat HTTP(S) goed gekozen is.

[Jerie]

Firefox installeren.

[bvanaerde]

Firefox is evengoed bezig om HTTP weg te werken. Het zou me dus niet verwonderen als ze binnenkort dezelfde beslissing zullen maken als Chrome.

[Engineer]

Sinds Chrome automatisch mee inlogt zodra je op Google/Youtube inlogt, heb ik Chrome eraf gegooid en Firefox erop gezet

Gaat me net iets te ver zulke ver gezochte automatische koppelingen.

[GeroldM]

Hoop dat je hierin geen gelijk krijgt. Tot die tijd aanbreekt (en vanaf nu) is FireFox wel mijn main browser.

[Blasterxp]

jup

[Anoniem: 306567]

Wel vreemd dat Google de update van chrome 69 weer had teruggetrokken door klachten van gebruikers, vervolgens gewoon doorvoeren in een nieuwe versie. Door dit soort praktijken ben ik een paar maanden geleden volledig overgestapt op Firefox. Ook omdat Chrome het Adblockers moeilijker gaat maken, moet zeggen dat ik volledig aan Firefox gewend ben en het een erg prettige browser vind om mee te werken.

[V3LoXy]

Ik denk dat dat eerder was omdat er redelijk wat bugs in voorkwamen, onder andere "subdomain.www.domain.com" werd getoond als "subdomain.domain.com" - dit is natuurlijk compleet fout. Er werden toen ook de "m" en "mobile" subdomein weggestript dacht ik.

Deze verandering zat er (helaas) wel (terug) aan te komen.

[laptopleon]

Eh… welke site gebruikt er nou subdomein.www.domain.com?

[YGDRASSIL]

Als de feature meteen teruggedraaid word na klachten. Heroverwogen en dan aangepast geherintroduceerd heb je in mijn ogen juist een zeer goed proces dat klantenmeningen niet negeert.

[mkools24]

Thx voor de tip. Beter dan een extensie.

[xoniq]

Het is ook belachelijk om voor alles maar een extensie erin te rammen met een zooi overhead aan code voor iets simpels als een 'flag'. Dit had ook prima een vinkje kunnen zijn in de instellingen van Chrome. Vreemd dat Chrome een geheugen draak is? Nee.

[Reactie gewijzigd door xoniq op 23 juli 2024 10:58]

[RoestVrijStaal]

Het loont meer om NIET Chrome te gebruiken.
Aangezien Google implementaties van onveilige W3C Drafts erin gooit die alles behalve stabiele (= door iedereen geaccepteerde) standaarden zijn (zoals WebUSB bijvoorbeeld). Dan doe je gebruikers van andere browsers zoals Firefox, Edge en Pale Moon ook een plezier mee.

Of een andere Chromium-gebaseerde browser gebruiken die (tot nu toe) standaard NIET die url-onderdelen verbergt, zoals Brave, Opera of Vivaldi.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 10:58]

[skaars]

..Of Edge (voor Mac en Win)

[tvtech]

Juist. Ik draai al een paar maanden op de nieuwe Edge. Werkt prima, wil niet meer terug, ook omdat het verschil niet groot is en al je extensies werken.

[Anoniem: 933945]

Heel fraaie tip dank u.

[cappie]

Mensen, just FYI: Firefox is de laatste 2 jaar echt verbeterd en de moeite waard om te installeren

[blinchik]

Inderdaad, Google voert steeds lastigere dingen door bij Chrome. Https verstoppen, subdomeinen verstoppen... Ik merk dat ik tegenwoordig terug vaker teruggrijp naar Firefox ...

[Anoniem: 80910]

Ik zou bijna zeggen, chrome voor de gebruiker, firefox voor de developer, maarja firefox is ook niet meer wat het geweest is, qualiteit soms ver te zoeken...

[kozue]

Wat is er dan mis met de kwaliteit van Firefox? Ik heb nergens problemen mee, alles werkt zoals het zou moeten.

[Anoniem: 80910]

mijn harddisk gaat naar de 100% in firefox, geen idee, monero o.i.d. herinstallatie werkt niet, zelfde issue

[real[B]art]

Om iets preciezer te zijn, alle 3 de opties die op chrome://flags/ verschijnen met de zoekterm 'omnibox-ui-hide' moet je uitschakelen om altijd de volledige URL te zien in de adresbalk (als je enkel zoekt op 'hide' verschijnt er ook een vierde, ongerelateerde instelling).

[FireStarter]

Idd.
Ik zie precies zo ook met bestandsextensies.
Voor sommige meer overbodige info voor de ander soms essentieel.

[Anoniem: 1076733]

In Nigeria zijn ze blij met deze move van Google!

[sjhgvr]

www ook?!
www.website.com kan totaal anders zijn dan website.com .. slechte ontwikkeling dit

[satisf]

Goh, theoretisch heb je gelijk, het zijn verschillende domains, maar praktisch is het eerder een zeldzaamheid dat dat relevant is. Uiteindelijk was www gewoon een conventie voor de publieke HTTP service op een bepaald hoofddomein. Later is dat WWW toch wel het belangrijkste van het hele internet geworden en dropten veel uitbaters dat onnodige www prefix, en maakten het gewoon een alias/redirect voor het hoofddomein. Je hebt vandaag nog sites waarbij geen HTTP(s) service draait op 1 van die 2 varianten, maar eentje waarbij een verschillende HTTP(s) service draait ben ik toch nog niet tegengekomen.

Ik vind het dus niet echt zo een gekke keuze, maar als je het zo belangrijk vindt, is het een goed moment om van browser te switchen, firefox laat mooi de gehele prefix zien .

[mcDavid]

Ik vind het wél een gekke keuze. Het is aan de site-maker om te kiezen op welk (sub)domein hij zijn site draait. Het www-subdomein is een uitstervend ras, en dat is wat mij betreft prima, maar door het te verbergen kunnen dingen gewoon stuk gaan of niet goed werken, zonder dat duidelijk is waarom. Laat de keuze om het te droppen dus lekker bij de sitebouwer, dit zijn typisch dingen waar een browser zich helemaal niet mee moet bemoeien.

[(TWIJG)]

Nog straffer, google.com zelf verwijst steevast door naar www.google.com!

[satisf]

Jij hebt als developer de keuze welk domein je gebruikt en hoe dat interract met DNS en HTTP services. Hoe dat domein weergegeven wordt in een browser heeft absoluut niets te maken met jou als developer. Niets houdt Google tegen ergens een publiek DNS register te gebruiken en www.mcdavid.com als ""mcDavid's site"" weer te geven, of zels gewoon de url bar te hiden nadat de pagina geladen is. Natuurlijk, als het over links/navigeren gaat, en dus bij uitbreiding ook het inttikken van een adres in de balk, moet een browser zich mooi aan de correcte gestandariseerde domain names houden.

Ja, google gaat hier in tegen hoe browsers het decennia hebben gedaan, maar er is geen enkele specificatie, contract, standaard, die zegt dat een browser een URL zo moet weergeven. Op zich is dit niet meer dan 'breken met traditie'.

[PhantomPotato]

Misbruik wordt op deze manier wil veel makkelijker en het overzicht is gewoon helemaal weg.
Dat Safari het path niet helemaal liet zien was voor mij al een reden het als onbruikbaar te beschouwen voor mijzelf en iedereen die ooit tech support van me wil verwachten.

[laptopleon]

Waarom zou hierdoor iets niet meer werken?

Ik krijg juist de indruk dat veel sitebouwers nog steeds www… gebruiken – erbij of zelfs als 'hoofd domeinnaam' – puur omdat ze bang zijn dat er anders een paar mensen het niet meer snappen. Na al die jaren vindt ik het niet vreemd dat iemand eindelijk de ballen heeft te zeggen: Het is mooi geweest.

[SunnieNL]

Ik heb op mijn domein wel een verschil in http en https… met https krijg je daadwerkelijk een inlogpunt te zien om op de systemen in te loggen. Met alleen http kom je in een readonly versie.

[vosManz]

Waarom redirect je eigenlijk niet alles naar de https variant? Door een http website in de lucht te houden is die http versie namelijk nog gewoon vatbaar voor een MITM aanval. Men kan dan ook inloggegevens stelen (je geeft aan dat er dan geen login formulier op de site staat, maar aanvallers kunnen die zelf toevoegen, zie opmerking van XIU) maar via een MITM aanval kan men wel bijvoorbeeld reclame of malware injecteren op je website zonder dat de bezoeker het door heeft. Ook is het voor de 'man in the middle' mogelijk te zien welke pagina de bezoeker precies bezoekt, terwijl bij HTTPS enkel het IP-adres of de domeinnaam (zonder path, IP of domein is afhankelijk van of de server SNI gebruikt) zichtbaar is. Door overal https te gebruiken voorkom je dat, en bescherm je dus zowel de veiligheid als de privacy van de bezoekers van je website.

[Reactie gewijzigd door vosManz op 23 juli 2024 10:58]

[XIU]

door de MITM kunnen ze net WEL op de http de login zelf toevoegen en zo de geldige credentials naar een eigen systeem sturen

[SunnieNL]

tja.. maar dat komt door google als ze de https weg gaan halen. Dan zie je het verschil niet meer en kunnen gebruikers niet controleren of ze op de juiste pagina komen.
Dat is het hele probleem van wat google gaat doen in de browser. Informatie weghalen waardoor controle door gebruikers lastiger wordt. Want zit ik nu wel op de http/https site of de www of root domain.

[Jorick]

Het verschil tussen http of https is nu juist een stuk duidelijker. Je ziet nu in het geval van https een slotje naast de domeinnaam en bij http een uitroepteken en 'not secure'. Dat is een stuk eenvoudiger te onderscheiden dan het verschil tussen http en https want daar lees je zo overheen. De meerwaarde van het tonen van www is ook nihil want het is maar een (default) subdomein en wordt in Chrome ook als zodanig behandelt. Het heeft voor de bezoeker geen meerwaarde, die hoeft alleen maar te weten of hij op het juiste domein is en of de verbinding naar de site veilig is of niet.

[vosManz]

Het eerste gedeelte over http/https ben ik met je eens.

Het tweede gedeelte over dat www 'maar een (default) subdomein is' niet. Allereerst is het niet default, een websitebouwer kan zelf bepalen of hij zijn site met of juist zonder www wil laten zien. Daarnaast kan www een compleet andere site laten zien dan zonder www.

Als voorbeeld, een sitebuilder waar je je eigen site kan maken. De sitebuilder is bereikbaar via 'sitebuilder.nl', en als je je aanmeld krijg je een URL als 'klantnaam.sitebuilder.nl'. Als ik nu een account aanmaak onder de naam 'www' en daar een phishing site op zet die visueel precies gelijk is aan 'sitebuilder.nl' gaat een gebruiker nooit het verschil zien, want die ziet in de adresbalk enkel 'sitebuilder.nl' in plaats van 'www.sitebuilder.nl'. En met een wildcard certificaat op sitebuilder.nl is die phishing site nog eens secure en voorzien van hetzelfde certificaat als sitebuilder.nl ook.

Uiteraard zou het van 'sitebuilder.nl' niet slim zijn om 'klantnaam.sitebuilder.nl' te gebruiken, of 'www' niet zelf te gebruiken of te blokkeren voor registratie. Maar feit blijft dat dit gevaarlijke situaties kan opleveren. Daarnaast kan er in de DNS aan 'sitebuilder.nl' een ander DNS record gekoppeld zijn dan aan 'www.sitebuilder.nl', en dat brengt ook weer risico's met zich mee. Maar in Chrome gaat de gebruiker daar niets van zien, want ze zien het verschil tussen www en niet-www niet meer.

[Jorick]

Allereerst is het niet default, een websitebouwer kan zelf bepalen of hij zijn site met of juist zonder www wil laten zien.

Het staat ook niet voor niets tussen haakjes. Het is geen strikte regel dat www default is maar het is wel zeer gebruikelijk om onder het www-subdomein je site te serveren. Het is zelfs zo gebruikelijk dat de meerwaarde om nog steeds www te typen of nog weer te geven niet maar aanwezig is. En ja, je kunt de meest rare constructies optuigen met domeinnamen, subdomeinen en DNS maar of dat verstandig is, is een tweede.

En zoals je zelf al aangeeft kunnen sitebouwers zelf beslissen wat ze serveren en/of ze gebruikers doorsturen als die binnenkomen op een 'naked' domeinnaam. Het zou een ander verhaal zijn als Chrome op eigen houtje gebruikers automatisch van http://example.tld zou doorsturen naar https://www.example.tld als ze dit eerste adres expliciet intypen maar daar is hier geen sprake van. Als jij naar google.nl gaat wordt je doorgestuurd naar https://www.google.nl omdat dit vanuit de server zo is geregeld. Als mensen de url gaan kopiëren/bewerken zien ze automatisch weer https://www. verschijnen.

In mijn optiek een storm in een glas water. Safari doet dit al langer en daar heb ik nog nooit iemand over horen klagen.

[Reactie gewijzigd door Jorick op 23 juli 2024 10:58]

[GeroldM]

Safari is een browser voor het Apple eco-systeem. Die gebruikers hebben zowiezo weinig keuze en hebben door de jaren heen geleerd dat klagen over Apple tegen Apple amper werkt. DSie hebben zich daarin al berust...en zijn daarom niet een goed voorbeeld om aan te halen.

[doom71]

Dus het feit dat jij bezoekers op een niet veilige pagina toelaat wat voor de bezoekers een risico oplevert is de schuld van Google? Bijzondere redenatie is dat. Je moet geen http site meer gebruiken. Zet beide gewoon op https.

[SunnieNL]

waarom zou ik een plain website in http zetten?
Ik vraag er niet om informatie van de gebruiker, geen cookies, reclame etc.. het is puur een informatieve statische pagina. Waarom moet ik daar de overhead van ssl overheen leggen met extra kosten voor een certificaat of meerwerk in beheer?

Wat voor risico loopt een bezoeker op een website waar het enige wat getransporteerd wordt statische informatie is naar die bezoeker toe? Wat levert een secure verbinding dan op?

[vosManz]

Zie mijn vorige reactie. Door een niet-http website aan te bieden kan een (MITM) aanvaller malware/reclame in je website injecteren, en kunnen ze precies zien op welke pagina je zit terwijl dat bij HTTPS niet mogelijk is. Zeker als je ook een https variant hebt waarop een inlogformulier staat, is het heel simpel voor een MITM om dat inlogformulier te injecteren op je http-variant maar dan met de aanpassing dat de logingegevens doorgestuurd worden naar de server van de aanvaller i.p.v. jouw server.

Je http-site is dus vatbaar voor het stelen van gegevens (na het injecteren van code), het bespioneren van je bezoekers, en het injecteren van malware en/of reclame.

[GeroldM]

Helemaal niets. Een certificaat geeft ook alleen aan dat de verbinding tussen jouw computer en de website die je bezoekt veilig is. De beheerder van de gecertificeerde website kan nog steeds gewoon alle rotzooi uithalen die maar mogelijk is.

De meeste mensen zijn ervan overtuigd dat de beheerder van een gecertificeerde site dat niet doet vanwege het certificaat. Gelukkig is dat voor het overgrote deel waar. Maar het is zeker geen vereiste voor het verkrijgen van een certificaat.

Een statische pagina met wat gegevens voor bezoekers erop is net zo veilig via http als https. Bied je echter interactie met de bezoekers aan, dan is de beveiliging tijdens het opzetten van de verbinding en gedurende de verbinding wel de moeite waard.

Regel je dat echter met gratis certificaten-leverancier LetsEncrypt (waarvan je dus echt niet van kan verwachten dat zij al de sites afdoende kunnen doorlichten voor ze hun gratis certificaten uitgeven), dan is https nog steeds meh.

Maar je browser "zeurt" niet meer, dus is alles wel weer ok. Als je dat gelooft, heb nog een mooie brug voor je te koop hiero.

Voor diegenen die blijven hameren op MITM aanvallen...ja, dat is een serieus probleem. Helaas niet het enige probleem. En zeer zeker niet de meest lucratieve. Je kan dan beter de server zelf aanvallen en daar je ongein uithalen. Helpt de beveiliging die https je biedt je bezoekers dus niet.

Een statische pagina is binnen een minuut weer teruggezet van een backup (die heel gemakkelijk te auditen valt). Het enige wat de beheerder dient te doen is de web server software en het OS up-to-date te houden. Dat houdt de meeste aanvallers wel tegen.

En er valt over het algemeen genomen maar weinig te verdienen (aan "street"-creds, of analoge/digitale valuta) met het aanvallen van een website met een statische pagina.

Eindelijk on-topic:
Laat Google al die info maar verbergen, dan verdienen Chrome gebruikers, die nergens op letten bij het klikken, om een (financiele) poot te worden uitgedraaid.

En kunnen ze met de overgebleven poot een browser downloaden die ze wel toont waar ze zich bevinden. Laten we hopen dat dit FireFox is en blijft.

[vosManz]

Je hebt helemaal gelijk, ik heb het even aangepast in mijn post

[Olifant1990]

Ging om verschil tussen met en zonder www

[kodak]

Wat de gedacht van diverse domeineigenaren was bij hun eigen implementaties is niet zo relevant. De standaard is dat een domein www.example.com een ander domeim is dan het hogere example.com. door gebruikers een ander idee te geven is Google niet bezich om het veiliger te maken.

[satisf]

Wat exact is er minder veilig aan? De enige attack vector die ik zie is dat als je www. verbergt ik kan doen alsof www.mysite.tld hetzelfde is dan mysite.tld . Echter, dan moet ik www.mysite.tld wel al kunnen hijacken via DNS of sterker, rechtstreeks in jouw HTTP service gaan zitten. In beide gevallen is er geen reden waarom ik niet gewoon mysite.tld ook kan hijacken, dus wat maakt het dan nog uit? Tenzij jij domweg natuurlijk je www subdomein doorverkoopt, maar eerlijk gezegd, dan nog moeten mensen op dat malafide www subdomein geraken (hoe krijg je ze daar) en of je dan die www toont of niet, daar gaat de modale gebruiker echt geen onderscheid tussen maken. Als de site lijkt op wat ze zoeken met of zonder TLD en er staat een groen vinkje (makkelijk te doen via letsencrypt) zullen ze het wel vertrouwen.

Maar, ik kan zeker attack vectors missen, dus vul gerust aan

Ik vind het best grappig overigens dat ik als exclusieve firefox gebruiker die niet eens chrome geinstalleerd heeft een beslissing van hen verdedig.

[kodak]

Als een verschil tussen domeinen en subdomeinen bestaat omdat het per definitie verschillende domeinen zijn en alles daaromheen in browsers en standaarden is gemaakt om er een grens in te hanteren voor duidelijkheid en veiligheid, dan lijkt mij eerder de vraag relevant hoe deze tegendraadse implementatie van Google de veiligheid en duidelijkheid ten goede komt.

Gebruikers dom maken, dom houden en op het verkeerde been zetten lijkt me geheel niet bijdragen om gebruikers bewuster te maken hoe (sub)domeinen werken en de juiste keuzes te maken.

[GoBieN-Be]

Iemand die voor een AD domain dezelfde domeinnaam gebruikt als voor z'n externe website is er een heel groot verschil tussen zonder WWW en met WWW.

[Tourmaline]

Ik heb in de praktijk ook wel gehad dat ik een website zocht en op dezelfde naam een ander bedrijf te zien kreeg.

[batjes]

Het weghalen van WWW is al 20 jaar een issue. Mozilla heeft dit in het verleden ook al een keer geprobeerd, volgens mij is het nog terug te vinden in about:config. Microsoft heeft er ook aan gedacht om dat www weg te laten vallen. Maar beide zijn hier destijds om goede redenenen vanaf gestapt. Nu gaat Google het proberen.... mkay.

Ik kom sporadisch nog steeds websites tegen waarbij www. en zonder toch doorleiden naar andere pagina's/servers. Het werkt al 30 jaar prima zo, waarom nu anders. Lekker extra verwarring.

[SF750]

Als je de details wil zien klik je gewoon even in de adresbalk. Wordt alles gewoon getoond.

[ELD]

Als je de details wil zien klik je gewoon even in de adresbalk. Wordt alles gewoon getoond.

Of je gebruikt Firefox.

[nelizmastr]

Idd. Vroeger was het argument om chrome te gebruiken de snelheid, maar die vlieger gaat sinds FF Quantum niet meer op.

[mschol]

dus de gebruiker moet maar actie ondernemen om iets te kunnen, ipv dat een programma dat gewoon al laat zien: de gebruiker is dus "ondergeschikt" aan het programma ipv dat de gebruiker centraal staat.

[Fly-guy]

Als 99% van de gebruikers niet eens weet waar je het over hebt, is het dan zo raar dat ze niet naar de resterende 1% luisteren als het gaat om het tonen van www.?

[Ralph58]

Dan kun je net zo goed het hele internet opdoeken.

[WhatsappHack]

Maar wat boeit het dat het er staat? Zit het subdomein in de weg...?

[Genosha]

Google wil dat je extra klikt, want klikken verbeterd de gebruiksvriendelijkheid

[marco-ruijter]

Ik denk dat jullie echt het gros van de browser gebruikers overschatten. De meeste mensen gaan nog steeds in Chrome naar www.google.nl om vervolgens daar een zoekopdracht te doen. Denk je dan echt dat die personen willen weten of ze op https of www zitten?

[Genosha]

Oh. Dat doe ik zelf ook, ik zoek nooit via de adresbalk en/of de zoekbalk in Firefox..

Maar er wordt al jarenlang door iedereen gewaarschuwd en leken aangeleerd te kijken naar de adresbalk. Zie je wel https?, klopt het adres wel? etc. etc. en nu haalt Google dat weg uit hun browser. Voor mijn ouders zijn www.winkel.nl en shop.winkel.nl twee verschillende websites, dit weghalen uit de url en alleen winkel.nl tonen zal onduidelijkheid geven. Zeker als er, zoals ik zei, al jaren wordt gewaarschuwd dat mensen op e-commerce sites moeten kijken of het adres in de balk wel begint met https.

[Keypunchie]

https wordt misschien op tweakers gezegd, voor de rest van de mensen was de marketing gericht op het 'slotje'.

Overigens zegt dat niet zo veel, want voor een malafide site, kun je nog zeer makkelijk een valide certificaat krijgen.

[arnold_m]

Ook bij uitleg over veilig internetbankieren wordt https genoemd, bijvoorbeeld (bron):
* Het internetadres begint met https://www.asnbank.nl/ als je op jouw computer, tablet of mobiel inlogt.

Er staan nog meer controles in het lijstje onder andere het al genoemde slotje, maar die zijn bij dit artikel minder relevant.
Bij andere banken staat waarschijnlijk een vergelijkbaar verhaal.

[Zoop]

Verschil tussen http en https zal nog wel te zien zijn, alleen niet in de adresbalk als een prefix. Maar eerder iets van een "onveilig" melding bij non-https.
En ik mag hopen dat ze alleen de www subdomein verstoppen, en niet ALLE subdomeinen, dat zou echt debiel zijn ...

[Sempai]

Het verstopt alleen www, niet andere subdomeinen

[JAVE]

En dan gaan ze binnenkort ook zeker .com verstoppen, want dat gebruiken alle websites toch (in amerika)

Ik zie ook helemaal het voordeel niet van het soms weglaten van het subdomein. (Dit staat los van het verstoppen van het protocol; daar kan ik nog wel iets in zien, aangezien er maar heel weinig reden is om geen HTTP(S) te gebruiken als je het web browsed.)

Laat mensen maar wat kennis opdoen, in plaats van alles 'makkelijk' te maken voor de meest simpele gebruikers.

Firefox heeft (had) het overigens ook, plus dat het een groot gedeelte van de URL in grijs (ipv zwart) toonde.
(Indertijd al die onzin uitgezet in de opties (about:config), dus ik weet niet of het nog zo is)

[Zoop]

En dan gaan ze binnenkort ook zeker .com verstoppen, want dat gebruiken alle websites toch (in amerika)

Dat lijkt me stug, want google verdient veel ste makkelijk aan hun custom tld's.

Bovendien bij een website.nl of www.website.nl praat je over het algemeen met dezelfde dns records, en dus ook doorgaans dezelfde servers (al KAN dat natuurlijk wel verschillen).
Het verschil tussen website.nl en website.com kan veel drastischer zijn (en wordt juist vaak gedaan voor phishing doeleinden).

Dus ik zie ze nog niet snel aan de tld's zitten.

[Ace]

Waarom die extra stap?

[Genosha]

Macht der gewoonte.

[Nox]

Nee, Google wil het voor Jan met de pet simpeler. Wij tweakers zijn te autistisch voor dit soort dingen.

[RoestVrijStaal]

Wij tweakers zijn te autistisch voor dit soort dingen.

Dat heeft er helemaal niets mee te maken. Wij (als in: sommige Tweakers) voelen aan onze klompen dat dit mis gaat doordat informatie om te valideren of je op de juiste website zit en een beveiligde verbinding gebruikt, verborgen wordt.

Daarnaast krijgen wij weer -als familielid met de meeste IT-kennis- de rest van de familie aan de telefoon en dan mogen we twee stappen extra zeggen: "Gebruik je Chrome?" "Klik eens op de adresbalk en kijk eens of de website met https en www begint". En dan mogen we nog van geluk spreken als de andere kant van de lijn weet wat Chrome en een adresbalk is.

Met andere woorden: het maakt ons "werk" lastiger, terwijl de verandering alles behalve nodig is.

[Reactie gewijzigd door RoestVrijStaal op 23 juli 2024 10:58]

[Nox]

Al eeuwen kijkt de simpele ziel naar een groen slotje. Als die om wat voor reden dan ook daar staat is het goed

Bovendien ben ik gestopt met dit soort ongein, alleen mijn ouders en zusjes krijgen support. Die hebben mij ook vaak genoeg geholpen. Van de rest hoor je nooit meer wat.

[RoestVrijStaal]

Helaas kan een MITM-aanvaller een groen slotje as favicon voor zijn fuik-website gebruiken.

Een scherp oog zal zien dat het pixelated is en/of dat de adresbalk ook niet groen is. Maar de meeste mensen kijken niet langer dan hun neus lang is en zien een groen slotje...

[Deakers]

Als je dit niet op prijs stel is het wellicht tijd om over te stappen op een andere browser.
Je zit toch niet aan Chrome vast ?

[D0phoofd]

Nou, Chrome heeft een redelijke vendor lock-in met een G-account. Dat merkte ik toen ik ging overstappen naar Firefox.

Al je gesyncte tabs, bookmarks, passwords, cookies en zelfs cache. Gone. Nu kan je je bookmarks nog wel makkelijk over zetten.

Ander ding is dat als je veel Google diensten gebruikt, zoals YouTube en/of Google docs, veel slechter af bent in een andere browser dan Chrome.

Zie ook:
https://fortune.com/2018/...w-mozilla-firefox-chrome/

[GeroldM]

Met je post zul je ongetwijfeld gelijk hebben. En ik verwacht dat deze post word ge-downmodded.

Maar goed, daar gaan we dan: als ik video wil bekijken op youtube met een niet op Chromium-gebaseerde browser, dan gaat dat in mijn optiek net zo goed. Nu moet ik daarbij wel aangeven dat het hele gedoe rondom de sociale aspecten van het bekijken van die videos me geen ene 'flying f.ck' kunnen schelen.

De vraag is dus: zit daar het verschil tussen chromium en niet-chromium browsers? Is het antwoord daarop ja, dan maakt de browser voor mijn doeleinden geen fluit uit en heb ik dus weer een reden minder om Chrome (of Chromium-based) browsers te gebruiken.

Google Docs (en andere online Office varianten) interesseren me ook helemaal niet. Ook hier weer uitleg: voor mijn documentatie doeleinden gebruik ik andere documentsvormen, welke veel beter zijn qua beheer, automatisatie, versiecontrole en doorzoekbaarheid. Zowel online alsmede offline en de methodes hetzelfde werken op Windows, Linux en Mac, waardoor documentbeheer zoals voorgeschoteld door (online) office producten gigantisch achterhaald aanvoelt.

[D0phoofd]

Als dat het argument is, waarom zijn mensen dan niet Edge aan het gebruiken?
Het is gewoon zo dat veel mensen direct een andere browser downloaden.
1. Omdat men een IE logo ziet (Edge logo lijkt ook op die van IE) en weten dat het troep is van oudsher.
2. Omdat ze kapot gespamt worden met pop-ups van google zodra ze op een van hun sites komen.

Wanneer die persoon dan ingeeft aan Chrome, is het ook direct een verademing. Want al die Google diensten werken ineens vlekkenloos. Plus het is ook gewoon een snellere browser. Zelfs nu Edge een Chromium engine gaat gebruiken, zullen ze Chrome downloaden.

En dan krijg je mond op mond reclame, en is Chrome ineens een populaire browser. Nu zijn ze het aan het inzetten als 'wapen' tegen de adblocker en anti-tracking add-ins. Want het eet uit hun eigen portomonee. Toch makkelijk, om als zoekmachine gigant je eigen browser te hebben.

[sjhgvr]

Waar lees je dat ik chrome gebruik?

[Brousant]

Leg dan eens uit waarom je het een slechte ontwikkeling vindt, als je er dus zelf geen last van hebt?

[Steephh]

Het is een slechte ontwikkeling omdat het verschillende URL's zijn. www.tweakers.net zou naar server A kunnen wijzen, waar tweakers.net naar server B wijst.

Sterker nog: er zijn websites die wel beschikbaar zijn wanneer je www.blaatwebsite.nl in typt, maar niet op blaatwebsite.nl

Google verbergt vervolgens www en dat kan verwarring veroorzaken voor "jan met de pet"

[Kees]

Sterker nog, www.tweakers.net bestaat niet eens als subdomein (het werkt alleen maar omdat we *.tweakers.net redirecten naar tweakers.net).

www moet dood, dit is een goede stap.

[mschol]

Sterker nog, www.tweakers.net bestaat niet eens als subdomein (het werkt alleen maar omdat we *.tweakers.net redirecten naar tweakers.net).

www moet dood, dit is een goede stap.

ik zou niet weten warom www dood moet?

www = website
op example.com host je imho andere services

[Kees]

Tegenwoordig is een domeinnaam synoniem aan een webservice. Je gaat naar google, je specificeert niet meer welk protocol en welk subdomein, je gebruikt nos.nl, niet www.nos.nl, je gaat naar nu.nl, je typed niet 'www.nu.nl' in. Vroeger was het mischien wel interesant (alhoewel ik dat betwijfel) omdat je toen vaker services had als ftp, gopher, finger etc. Domeinnamen zijn nu zo cheap dat ik ze zelfs gewoon als servicenaam gebruik, bijvoorbeeld tweakdns.nl.

Bijna niemand ziet een domeinnaam nog zoals het is: de naam voor je hele domein/netwerk waarin je verschillende hosts hebt draaien en aparte services aanbied en waar elke service basically een eigen IP nodig heeft omdat het een aparte fysieke machine is. Met de huidige proxies en firewalls is dat ook helemaal niet meer nodig. Sterker nog, de tijd dat een domeinnaam voor een enkel netwerk is ligt al lange tijd achter ons.

Dat er andere services zijn dan webservices is voor 99% van de internet gebruikers niet relevant. Bovendien specificeer je die bijna altijd met een protocol of je gebruikt een specifiek programma.

En het scheelt dataverkeer. Wij doen zo'n 20 miljard requests per jaar, 4 bytes minder scheelt dan bijna 80GB

[eric.1]

Maarja, als je een website hebt die voor jan met de pet bedoeld is...dan heb je gewoon een disgnfout gemaakt indien www en niet-www bewust een andere pagina voorschotelt, of een er van gewoon helemaal niets.

De verwarring wordt niet door het verbergen van www veroorzaakt, maar door incapabele website bouwers.

Denk je dat iemand handmatig www (of juist niet) in typt als de andere versie niet werkt? Dan drukken ze gewoon op "terug" en bestempelen ze de website als kapot.

[Steephh]

Dat het een (slordige) fout van de website bouwer is en verwarrend voor gebruikers, eens!

Echter helpt in dit geval essentiële informatie uit het adres weg laten niet mee aan de gebruikerservaring. Het insinueert dat het ook zonder www. zou werken, wat gewoonweg niet waar is.

[eric.1]

Naja, dan zullen website bouwers dus vanaf Chrome 76 moeten zorgen dat het wel beiden hetzelfde werkt. En dat is onder de streep gewoon positief voor de gebruikerservaring .

Ik ben zelf ook niet voor het verbergen van informatie. Maar voor jan met de pet maakt het weinig uit. Zolang de browser maar piept bij certificaat issues.

[SunnieNL]

"deze site is niet geschikt voor chorme 76 of hoger. Gebruik Firefox en gaan naar www.mijnsite.nl"

[StefanJanssen]

Omdat informatie verbergen dingen alleen maar ingewikkelder maakt, het is niet dat er ruimtegebrek is waardoor het wegmoet.

[sjhgvr]

Volg jij ooit het nieuws? Genoeg slechte ontwikkelingen in de wereld.
Heb zelf echter geen last van de dingen die aan de andere kant van de planeet gebeuren.

[sjhgvr]

Leg dan eens uit waarom je het een slechte ontwikkeling vindt, als je er dus zelf geen last van hebt?

Daarmee toon ik aan dat je ontwikkelingen slecht kunt vinden, zonder er last van te ondervinden.
Maar heb je enig idee hoe offtopic we nu gaan? .. wait.. don't answer that..

[jeroen3]

Lijkt erop dat alleen het protocol is verborgen. En dat is prima, want voor veel mensen is dat toch overbodige informatie.

[HollowGamer]

Je noemt het een slechte ontwikkeling, maar dat kan je ook andersom zo benoemen. Welke ontwikkelaar/webbeheerder doet nu 2 verschillende dingen draaien op/zonder www. subdomain? Normaal gesproken redirect je die naar je voorkeur (hint: zonder www als hoofd zoals hier op T.net - dat is het meest gebruiksvriendelijk).

Ik kan mij echt niet voorstellen dat je dit wilt, maar ben al gekkere dingen tegenkomen zoals niet werkende https redirects.

[Reactie gewijzigd door HollowGamer op 23 juli 2024 10:58]

[doom71]

Nee joh. Al die andere browser makers zijn veeeeeel beter. NOT!

[demartijn]

Als google alleen een browsermaker was geweest had ik er geen problemen mee gehad.

[Johnvh]

Safari doet dit al tijden en toont zelfs de url structuur van de pagina niet eens.
Daar is het met een setting eenvoudig uit te zetten maar ook ik begrijp deze ontwikkeling niet. Om een zo veilig mogelijk internet te hebben is het toch alleen maar goed om mensen te laten zien op welke URL ze aan het browsen zijn?

[fretnn]

Phishing speelt in op het feit dat mensen niet altijd even aandachtig zijn.

Zie mijn andere comment om een voorbeeld te zien waar dit systeem net beter is

[Ionicawa]

Obfuscatie van waardevolle informatie ten behoeve van 'simpliciteit' vind ik altijd een kwalijke zaak. Ja, het ziet er simpeler uit, maar maakt dat het duidelijker, of juist verwarrend? Ik denk eerlijk gezegd dat het verwarrend is, aangezien er een verschil kan zijn tussen www.domain.com en domain.com

Wat wint de gebruiker hier nou mee? 20 pixels in de adresbalk? Ik zie het nut niet zo.

[LordMike]

Uniformiteit?

Dit betekent letterlijk ook het einde van het hele 'www' verhaal en je kan nog steeds opteren om eender welke andere sub-domein te gebruiken.

Je verliest amper 1 subdomein maar er blijven er quasi onbeperkt over?

Als websitebeheerder zijn er wel veel andere belangrijkere zaken veranderd dan het wel of niet tonen van de www.

Hoeveel consumenten/gewone gebruikers begrijpen dit? Tweakers, okay, en de rest?

[mae-t.net]

Als ik het zo eens overdenk, lijkt me niet dat het zozeer om het "simpeler maken" gaat, maar om het hele internet achter een grote zoekbalk te stoppen zodat de gebruiker uiteindelijk het verschil niet meer ziet.

[Nick van Korven]

Ik heb het uitgezet bij chrome://flags/ en dan bij hide.

[maartenvdezz]

Hoe heet de flag?

[Anoniem: 84766]

Zelfde als Safari het nu al lange tijd doet dus.

Ter verdediging van Google, gebruikers reageren niet op changelogs. Developers en techneuten doen dat.

[mschol]

gebruikers reageren sowieso niet of slecht, die hebben namelijk weinig tot geen manieren om echt te reageren (behalve een browser switch, maar dat doet gemiddelde gebruiker ook niet)

[Anoniem: 84766]

Klopt, en ook ik ben van mening dat dit een verbetering is voor de gemiddelde gebruiker:

Duidelijk:
(Groen) Slotje -> website.com

Een brei van letters waar de gemiddelde gebruiker niet eens naar wil kijken want het is chinees:
Groen -> slotje -> https://www.website.com/b...564645745&search=dffdgfdg

[Bakove]

Das niet echt een eerlijke vergelijking. Het is:

(groen) slotje -> website.com
vs.
(groen) slotje -> https://www.website.com

OF:
(groen) slotje -> https://www.website.com/b...564645745&search=dffdgfdg
vs.
(groen) slotje -> website.com/blaat-test/page?sdgfkfdkg=5645645dfg,46546gddgh,457547gdf,457gdfgd564645745&search=dffdgfdg

Ik denk dat t voor de gemiddelde gebruiker geen ruk uitmaakt. Doorgaans trekt die hele adresbalk mijn aandacht totaal niet tijdens het internetten.

[Anoniem: 84766]

Bij Safari werkt het niet zo. Ik zie nu slotje tweakers.net

Verder boeit die adresbalk inderdaad niet, behalve met bankzaken etc waarbij de gebruiker er ook extra op gewezen wordt. Dan denk ik dat hoe cleaner, hoe beter.

[Bakove]

Aha, ik heb geen ervaring met Safari.

In Chrome 76 is het: slotje tweakers.net/nieuws/155712/google-haalt-etc

[Depress]

Dat is gelukkig zonder een plugin ook weer in te schakelen:
Advanced -> Smart Search Field [X] Show full website address

[Paul]

Als ze het deel dat ze niet weergeven dan in ieder geval ook niet in je copy/paste-buffer zetten.

@#$@#$@#$ annoying als je denkt "tweakers.net" te kopiëren en er na het plakken "http://tweakers.net" staat... (ok, slecht voorbeeld want Tweakers gebruikt HTTPS, maar @work regelmatig last van als ik aan het troubleshooten ben met een IP-adres bijvoorbeeld).

[maartenvdezz]

Ik vind het júist bloedirritant als je na het plakken van de URL nog zelf moet uitvogelen of het https of http is...

[Paul]

Waarom? Gewoon op enter drukken?

Ik zou graag zien dat browsers default HTTPS gebruiken en als dat niet werkt terugvallen op HTTP, maar met HSTS regelen meer en meer sites dat zelf.

[mkools24]

Dat www weglaten, tegenwoordig zie je toch meer dat de apex (root domain) wordt gebruikt voor de site. Ik heb sowieso het idee dat www een beetje uitgestorven is maar ik zie hier het nu niet zo van in, beetje wijzigen om het wijzigen lijkt het.

[Cyb]

www is helemaal niet uitgestorven. Voor veel sites is het technisch een vereiste, vanwege cookies. Des te groter de site (of des te meer subdomeinen een site gebruikt), des te groter de kans is dat je www ziet.

Voorbeelden die het gebruiken: Facebook, Instragram, Google, Wikipedia, Apple, Youtube, Yahoo, Amazon, Netflix, Pornhub, Reddit, Linkedin, Microsoft, eBay, Bol.

[faim]

Voor veel sites is het technisch een vereiste, vanwege cookies. Des te groter de site (of des te meer subdomeinen een site gebruikt), des te groter de kans is dat je www ziet.

Leg eens uit dan? Cookies werken prima op (alleen) het hoofddomein. Subdomeinen werken prima zonder een www subdomein.

Ik ben persoonlijk ook geen voorstander van www, het is slechts een subdomein wat nergens voor dient, puur om vroeger mee aan te duiden dat het een world-wide-web adres betroft. Tegenwoordig is het voor iedereen duidelijk dat microsoft.com of startpagina.nl een webadres is. Ook was het hip om verschillende services op verschillende subdomeinen te gebruiken. Vooral op zijn Engels is het een onheil, double-u, double-u, double-u, daar heb je meer tijd voor nodig dan voor het uitspreken van de rest van het adres.

[Cyb]

Het kan zijn dat ik iets over het hoofd zie, want de hele RFC geschiedenis kwa cookies, is nogal een zooitje met al die wijzigingen.

Vaak is het kwa security ongewenst dat cookies op een hoofddomein door een subdomein gelezen kunnen worden. Dit is de reden waarom grote sites (die ik hiervoor heb genoemd, in de post die -1 heeft gekregen) www gebruiken. Zonder www zou bijv. de cookies van example.com lekken naar thirdparty.example.com, wat een security probleem kan zijn. Tegenwoordig zijn er mogelijk wel middelen om te probleem te voorkomen, maar niet elke browser ondersteunt het. Vandaar dat grote sites www gebruiken.

Ik vind het zonder "www" overigens ook mooier, maar het is voor sites vaak een technische reden om www te gebruiken.

[boe2]

die gewoonte ga je er nog niet meteen uitkrijgen bij veel gebruikers:
"oke oma, surf naar tweakers.net"
"dus WEEE WEEE WEEE punt tweakers punt net?"

[EnigmaNL]

Wat een slechte en onnodige ontwikkeling.

Waarom is Google zo lui dat ze er niet eens een instelling voor in het menu zetten om dit weer te herstellen?

[Rob]

Voor de gewone gebruiker wordt het allemaal wat simpeler
Voor de webdev, zoals in een ander comment wordt opgemerkt, kun je in chrome://flags/ dit weer uitschakelen