Chrome 69 verbergt subdomeinen als 'm.' en 'www.'

Google Chrome versie 69 vertoont standaard niet meer de 'm.' en 'www.'-subdomeinen in de adresbalk. Volgens de ontwikkelaars is dit subdomein 'onbeduidend' en daarmee overbodig, maar zeker bij 'm.' is er wel een wezenlijk verschil in waar de gebruiker terechtkomt.

Chrome 69 werd op 4 september gepropageerd in het releasekanaal. Opvallend is dat de maatregel nergens genoemd wordt in de changelog van de applicatie. Dat geldt voor de aankondigende blogpost en de volledige changelog met commits. De motivatie voor de verandering is dan ook alleen te vinden voor wie naar de relevante flag navigeert. Bij het bewerken van de adresbalktekst verschijnt het subdomein wel en de optie is nog te togglen.

In een discussiepost op het Chromium-forum zetten gebruikers zich hard tegen de verandering af. Een reageerder, die zegt dat hij voor een internetprovider werkt, noemt de verandering dom. Dit omdat de aan- of afwezigheid van 'www.' in bepaalde gevallen leidt naar een twee verschillende bestemmingen. Dat geldt uiteraard ook voor 'm.' Goede voorbeelden zijn tumblr.com en m.tumblr.com; dit zijn twee verschillende sites die nu exact hetzelfde eruit zien in de adresbalk.

Een andere reageerder tekent aan dat het systeem zich ook vreemd kan gedragen. De voorbeeld-url 'subdomain.www.domain.com' verandert in 'subdomain.domain.com'. Zelfs wanneer het 'triviale' subdomein in het midden van een url staat, wordt het weggehaald. Een ontwikkelaar erkent wel dat dit een bug is die gecorrigeerd moet worden.

Google heeft kort geleden al eerder te kennen gegeven dat het de url in de toekomst niet langer wil weergeven in Chrome. Adressen zouden te ingewikkeld geworden zijn, wat gebruikers kan verwarren en ze kwetsbaar maakt voor door kwaadwillende gemanipuleerde url's. Google wil dit bestrijden, maar zonder dat onduidelijk wordt op welke site een gebruiker zit. Deze wijziging zorgt er echter wel voor dat het minder duidelijk is waar een gebruiker zich precies bevindt.

Links tumblr.com en rechts m.tumblr.com

Reacties (234)

[Verwijderd]

Ik snap het security argument totaal niet. Door minder informatie van een URL te tonen, heb je alleen maar minder context, het is onveiliger, niet veiliger. Dat de meeste gebruikers URLs toch al niet begrijpen is niet relevant, een groot deel begrijpt ze wel, en voor de rest maakt het niet veel uit of deze kort of lang is.

De daadwerkelijke reden is schijnheilig: AMP. Met Google AMP paginas bezoek je paginas terwijl je nog steeds op het Google domein zit. Wat ze op veel kritiek komt te staan. Dit is een van meerdere stappen om dit te verdoelezen, uiteindelijk.

[pe1dnn]

Ik snap het security argument totaal niet. Door minder informatie van een URL te tonen, heb je alleen maar minder context

Deze ellende is jaren geleden al begonnen, toen is men doodleuk het transport protocol weg gaan laten, terwijl http://www.google.com toch echt wat anders is dan ftp://www.google.com of gopher://www.google.com of wat voor ander transport protocol men wenst te gebruiken. Voor https:// moet je opeens naar een slotje kijken terwijl je meteen aan het volledige adres kan zien dat het https en dus hyper text transport over SSL is. Gewoon omdat men "http://" intypen niet mooi vindt. Teleurstellend is dat zelfs Firefox door de knieën is gegaan en die "http://" uit de URL in de adresbalk haalt (gelukkig ook weer ongedaan te maken).

Mensen die dit soort beslissingen nemen hebben 0% verstand van techniek. Dat zijn dezelfde product managers die ooit bedacht hebben om een filenaam maar half te laten zien door de extensie weg te laten. Moet je opeens aan een pictogram zien wat voor document het is en zie je alleen nog maar een sub string van de hele filenaam. Gelukkig is het instelbaar gemaakt en onder Windows is dat verbergen zo ongeveer het allereerste dat ik uit zet. Nog een reden om Linux te gebruiken, die verbergen nooit zomaar gewoon stukken van de filenaam voor de gebruiker.

[Reactie gewijzigd door pe1dnn op 26 juli 2024 20:49]

[mashell]

Maar is een extensie eigenlijk wel deel van de bestandsnaam? Of het een stuk metadata dat vroeger per ongeluk, toen de techniek nog niet zo ver was met een puntje aan de bestandsnaam vastgeplakt geraakt is? Een goede user interface verbergt technische implementatiedetails voor de gebruiker. Dus file extensies laat je weg. Ook gebruikte transportprotocollen zou je eigenlijk moeten verbergen. Ook zinloze prefixen als www. Eigenlijk zelfs administratieve zaken als domeinen, hoewel dat door lokale uitgiften niet kan.

[wdelange]

Als je in Dos bent begonnen is de extensie echt wel een filenaam en filenaam.txt is een ander bestand dan filenaam.docx. Maar de extensie is geen metadata, maar een reminder wat de file voor content bevat.

Als het metadata, dan moet je het hele OS omgooien. Er zijn wel OS'en waar de extensie niet gebruikt wordt en de eerste bytes van de file de metadata bevat. Maar dat heeft zoveel consequenties voor alles, dat je het beter maar achterwege kan laten. Het is te laat om nu nog over te stappen, zonder dat het zeer veel problemen oplevert.

www is net als een extensie geen zinloze extensie. Er zijn websites die met www anders reageren dan zonder. Wel geldt dat www. een soort variant is geworden voor http://. World wide web is graphisch zichtbaar, tewijl ftp voor file structuren staan. Wat je ook ziet bij de grote bedrijven is dat ze .com en .nl willen weglaten, het domein. Alles wat google is, is toch al gereserveerd. Moet kunnen. Alles onder google, microsoft en facebook onderbrengen en domeinen zijn ook niet meer nodig.

[mashell]

maar een reminder wat de file voor content bevat

Metadata dus. Het beschrijft hoe het bestand is gestructureerd. En dat readme.txt wat anders is dan readme.doc is vanwege de 8.3 beperking van vroeger maar zuiver zou zijn dat het bestand gewoon readme zou heten en in een folder er maar eentje van zou kunnen zijn. In de IT slepen we jaren oude legacy maar met ons mee (we doen net of we hip en modern zijn maar we zijn eigenlijk heel conservatief en hebben veranderingsangst).

www is net als een extensie geen zinloze extensie. Er zijn websites die met www anders reageren dan zonder. Wel geldt dat www. een soort variant is geworden voor http://

Die laatste zin maakt eigenlijk dat prefix www. inmiddels wel zinloos is. Dat sites anders reageren is eigenlijk gewoon een slecht ingerichte site. Er wordt teveel vanuit de technische mogelijkgheden gedacht en te weinig vanuit de gebruiker.

[pe1dnn]

Metadata dus. Het beschrijft hoe het bestand is gestructureerd.

Dat het het probleem, het beschrijft helemaal niets maar spiegelt een gebruiker wat voor. Ik kan prima een readme.jpg maken waar gewoon ASCII tekst in staat. Windows gebruikt het om het programma te voeren aan een foto applicatie puur omdat het toevallig .jpg heet, bij deze readme.jpg gaat het meteen de mist in omdat het gewoon tekst is. En wat hebben we al een ellende gehad met bestanden die zich voordoen als iets anders. Het is gewoon een krakkemikkige oplossing om zomaar blind op een filenaam te vertrouwen en daarmee conclusies te trekken over de inhoud. Geef mij maar het Unix "file" commando die echt in de file kijkt wat het is en niet blind afgaat op een veel te gemakkelijk te manipuleren extensie. En als je niet wil dat gebruikers extensies zien, gebruik die dan ook helemaal niet. Zet die dan ook niet in de filenaam, de filenaam is helemaal geen geschikte plaats voor metadata, als het de naam "metadata" al mag hebben.

[mashell]

Ik ben het roerend met je eens. De file extensie is een problematisch overblijfsel uit een verleden. Daar zouden we vanaf moeten. Eigenlijk zou er een nieuwe universeel bestandsformaat gedefinieerd moeten worden waarbij alle metadata bij elkaar zit. Met een blockchain achtig concept waarbij alle manipulaties van het bestand worden gedocumenteerd.

[KopjeThee]

Wat een terechte constateringen! Je hebt een goede consistente, eenduidige naamgeving, en vervolgens verrommel je het. Het verduidelijkt niets. Integendeel, het zaait verwarring. En verwarring is potentieel zelfs onveilig.

[sdk1985]

FTP moet je wat mij betreft als browser uberhaupt niet oppakken. Kan eventueel met de file explorer, maar het liefst met een geschikt stuk software. Als je er nu vanuit gaat dat je met je browser alleen http en https gebruikt, waarom zou je dat dan elke keer weergeven? Hetzelfde voor www. Het voegt gewoon niets toe.

Mbt de file extensies zou ik het eerder omdraaien. We praten hier overigens over een functie waarvan ik zeker weet dat die al aanwezig was in windows 98 (!). Unix werkt uberhaupt anders, daar zijn bestanden zonder extensie prima (Gnome verbergt overigens .desktop). Diegene dit het nut van het verbergen van die bestandsextenties niet snappen zullen geen kaas van user experience gegeten hebben. Probeer er eens anders naar te kijken. Wat heeft de gemiddelde gebruik er nu aan om te weten of zijn bestand .doc, .docx, docm, enz is. Natuurlijk een retorische vraag, daar heeft die gebruiker niets aan. Waar die gebruiker wel last van heeft is information overload. Wellicht kun jij goed veel informatie verwerken en heb jij er geen probleem mee maar er zijn legio mensen die wanneer ze een grote lijst met informatie zien gewoon helemaal uitschakelen. Die kunnen daar niet mee overweg. Voor die groep mensen is dit soort instellingen de standaard.

Verder is er nog een tweede reden dat de extensies standaard verborgen zijn bij windows. Hernoem je namelijk het bestand en verwijder je per ongeluk de extentie dan kun je het bestand niet meer openen. Daar zit dan ook meteen het verschil met Unix. Daar heb je geen extentie nodig om het bestand te openen.

We praten hier overigens over een functie waarvan ik zeker weet dat die al aanwezig was in windows 98 (!). (En heel flauw maar Gnome verbergt .desktop).

[Reactie gewijzigd door sdk1985 op 26 juli 2024 20:49]

[morfanaion]

Ten eerste geeft Windows al een waarschuwing als je de extensie wijzigt, als je dan toch doorklikt en er daarna niets aan doet, dan ben je sowieso verkeerd bezig. Je kunt domheid nooit helemaal uitbannen. Dat het wenselijker is om uit de contents van een file op te maken wat deze bevat ben ik op zich met veel mensen wel eens, maar we zitten nu eenmaal met heel veel legacy bestanden die daar nimmer aan gaan voldoen en een breed scala aan besturingssystemen die allemaal bestanden met elkaar uitwisselen. Een dergelijke wijziging is daarmee zeker geen sinecure en er gaat minimaal 15 jaar overheen voordat een dergelijke standaard echt gaat werken.

Zolang we in Windows nog op basis van extensie werken is het verbergen van een extensie simpelweg een risico. Het is namelijk een zeer kleine moeite om een programma te schrijven dat als icoon gewoon het icoon voor een Word Document heeft. Gebruikers die de extensie verborgen hebben zullen er daarop van uit gaan dat ze een Word Document open, maar in plaats daarvan gaat er een programma draaien. Leuke manier om keyloggers en dergelijke te activeren. En dit is in het verleden dus ook werkelijk gebruikt: https://www.zdnet.com/art...eware-of-those-pif-files/

Informatie standaard verbergen voor je gebruikers onder het mom van gebruiksgemak is gewoon een fout. Security wordt in deze wereld steeds meer een issue en iedereen vindt er wel wat van, maar zodra het woord gebruiksgemak valt, worden veel security bezwaren overboord gekieperd, mijns inziens een gevaarlijke ontwikkeling.

[Verwijderd]

Ik ben het helemaal met je eens behalve dit:

"Mensen die dit soort beslissingen nemen hebben 0% verstand van techniek"

Google kun je van veel beschuldigen maar niet van dit. Men weet echt wel hoe de techniek werkt, men misbruikt het om de eigen agenda door te drukken.

[Gamebuster]

Hey, iemand die het snapt!

Safari (osx/ios) doet het overigens al een tijdje ook nog nooit ergens iets gezien of gelezen over misbruik of klachten.

[Reactie gewijzigd door Gamebuster op 26 juli 2024 20:49]

[stresstak]

Het kan natuurlijk zijn dat die gebruikers niet nadenken over misbruik en mogelijke onveiligheden.
Windows' gebruikers weten als geen ander dat er gevaren loeren bij hun systeem.

[Gamebuster]

Of de theorie die minder aannames bevat: Er is geen veiligheidsrisico. Het is gewoon een kwestie van smaak en ongefundeerde angst.

[rene_fb]

Op de een of andere wijze vind ik dat op iOS ook maar irritant. Ik weet niet waarom, het zal wel tussen de oren zitten, maar geef mij maar de hele URL.

Ik zal daarnaast wel onder een steen geleefd hebben, maar tot een paar dagen terug nog nooit van AMP behoort, maar verbaasde mij steeds vaker dat als ik een site bezocht, in de adresbalk gewoon een google.com domain bleef staan.

Beetje off-topic: bij de Googles, Facebooks en al het gestuurde en beïnvloeden nieuws vanuit welke hoek dan ook moet ik steeds vaker aan de film 'Tomorrow Never Dies' denken.
De film is ruim 20 jaar oud, maar de realiteit schijnt de fictie bijna in te halen...

[Blizz]

Klachten zijn er genoeg, daarom zijn er ook jailbreak tweaks om weer de volledige URL weer te geven of andere features toe te voegen aan Mobile Safari. Voor de gemiddelde consument zal het verder worst wezen, daarom zul je dit daar niet vaak terughoren, eventueel instemming als iemand anders het opbrengt. Misbruik zal het ook niet zijn, Apple is geen web-bedrijf zoals Google en doet het alleen maar omdat het ordelijker is, je er zeker als gemiddelde gebruiker nooit naar hoeft te kijken tenzij je het adres wijzigt en omdat je focus zo met minder afleiding op de content kan blijven.

[OddesE]

Ik snap het security argument totaal niet.

Ik wel. Zeker voor mensen die moeite hebben met het onthouden van urls. Ga niet zelf zitten typen, en klik al helemaal niet op links in e-mails, maar zoek de site op Google. Want een phishing site vind je niet met Google. Als jij zoekt op "rabobank" dan vind je dé Rabobank en niet een andere site. Terwijl als je op een link klikt of zelf typed en dan wellicht een spelfout maakt dan kom je misschien wel op de verkeerde site terecht.

Ok, ik geef toe een beetje advocaat van de duivel modus, maar er is zeker wel een argument te maken.

[svenslootweg]

Want een phishing site vind je niet met Google. Als jij zoekt op "rabobank" dan vind je dé Rabobank en niet een andere site.

Wat een onzin. Er bestaat letterlijk een hele industrie rondom het misbruik van Google-advertenties om zo mensen naar phishingpagina's danwel oplichtingspagina's te leiden, doordat die prominent op de pagina weergegeven worden.

De kans dat je via Google op een oplichtingspagina terecht komt, is vele malen groter dan de kans dat dat gebeurt door een typo in de URL. Bij Google hebben adverteerders immers controle over wat er getoond wordt voor een zoekopdracht, terwijl een oplichter bij een typo maar moet hopen dat je precies die typo maakt.

[Verwijderd]

In een auto geeft het dashboard toch ook alleen maar relevante informatie en worden de details achter de schermen geinterpreteerd Dat zou bij een browser die door "gewone" mensen wordt gebruikt ook zo gaan. Security risico's moeten door de applicatie worden geanalyseerd en op een eenvoudige wijze aan gebruikers worden getoond.

ICT zou ondertussen toch wel zo volwassen moeten zijn. En PC (en veel applicaties) is nog altijd een gebruiksonvriendelijk apparaat als je het vergelijkt met alle andere producten die op de markt zijn. Goed dat Google probeert om het simpeler te maken.

[svenslootweg]

Het probleem is dan ook dat er hier vanuit gegaan wordt dat een URL "irrelevante informatie" is. Dat is het niet; het is een fundamenteel onderdeel van het open web, en als gebruiker moet je gewoon leren daarmee om te gaan, en is het niet wenselijk om welk onderdeel dan ook ervan te verbergen.

Dat betekent natuurlijk niet dat je de implementatiedetails hoeft te kennen, maar als URLs verborgen worden want "dat is te ingewikkeld" dan gaat er echt iets heel erg fout.

EDIT: Om daar nog even verder op in te gaan: Google heeft het over 'website identity'. Maar dat is helemaal het doel van een URL niet; het doel van een URL is om een persistent identifier te zijn voor een resource. Een referentie waarmee je een bepaalde pagina op kunt vragen.

Dat past echter niet binnen Google's (en Facebook's, en Twitter's...) idee van het web; namelijk als platform dat dient om specifiek hun (gecentraliseerde) diensten over te leveren, in plaats van een open web. Dit is vermoedelijk waarom Google probeert URLs te rebranden als iets dat met 'website identity' te maken heeft.

In dit perspectief is het een stuk duidelijker waarom een URL gewoon belangrijke informatie is: het is een persistent identifier voor de pagina die je bekijkt, een manier om er elders aan te refereren.

[Reactie gewijzigd door svenslootweg op 26 juli 2024 20:49]

[mashell]

Is het google die dat wil of is het de gebruiker die dat wil? Want die hele technocratische benadering van het internet past eigenlijk niet bij de hedendaagse gebruiker, wat gewoon iedereen is. Daarom zijn gebruikte transportprotocollen en subdomeinen met namen die refereren aan transportprotocollen oninteressant. Een URL is iets technisch, voor de inhoud niet relevant en moet je dus eigenlijk de gebruiker niet mee lastig vallen. Bij email worden de mailheaders ook al jaren niet meer aan de gebruiker getoond. Het gaat om de inhoud, niet om de techniek. Eigenlijk is het gewoon een teken van het volwassen worden van het internet, de techniek werkt, de details daarvan worden voor de gebruikers steeds meer irrelevant en verborgen. Voor ons techneuten niet leuk maar het is dan ook steeds minder iets technisch.

[I-King]

De 'flag' staat wel gelinkt, maar even voor de duidelijkheid, je kunt dit uitzetten: Navigeer naar chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains, zet deze op 'disabled'.

[Dysmael]

Mooi, weer een stukje beveiliging dat wegvalt doordat Chrome belangrijke info niet laat zien.
Bekijken van TLS certificaat is al hoge wiskunde geworden,
Nu moet ik dus, als ik de URI ter controle wil zien één of ander lange string gaan zitten onthouden.

[I-King]

Nee, bovenstaande instructie is een instelling, die zal werken zolang Chrome dat ondersteunt.

[Dysmael]

Ja dus? Het is wel een instelling die ik moet kennen en moet uitvoeren. Het is opt-out ipv opt-in

[ksborg]

Dit inderdaad. De reden dat ik afgelopen week op m'n werk PC over ben gestapt naar Firefox. Chrome verwijderd. Leuk dat er een optie is, maar maak hem dan zichtbaar en beschikbaar. Voorlopig prima blij met Firefox en dus thuis ook maar even switchen met alle PC's

[spNk]

Sinds Firefox Quantum zie ik ook echt geen rede meer om over te stappen naar Chrome. Firefox is nu minstens zo snel als Chrome namelijk, zonder de fratsen en waardeloze instellingen-menu.

[HansvDr]

Amen. Gewoon Firefox. Geen dubbele agenda en geen reclamebedrijf.

[wica]

Is dit een setting, die zo blijft. Ook al update Chrome zich.
Of zal je dit bij elke update weer moeten gaan aanpassen?

Soms worden er vieze spelletjes gespeeld, met onze instellingen.

[Verwijderd]

> Google heeft kort geleden al eerder te kennen gegeven dat het de url in de toekomst niet langer wil weergeven in Chrome.

In een tijd van scamming en phishing lijkt mij dit niet echt wenselijk. Dit doet mij denken aan wat Windows standaard doet met bestanden, door de extensie van een bestand te verbergen. Daardoor is voor de meeste mensen geen onderscheid meer te maken tussen echte afbeeldingen, of uitvoerbare bestanden die IMG_6592.JPG.exe heten.

Wat ik wel een goede ontwikkeling vind is wat Firefox doet met domain highlighting. Zo zie je direct op welke url je zit en valt het veel meer op als er sprake is van phishing, zoals rabobank.nl.some-other-site.ru, waarbij juist some-other-site.ru opvalt.

Overigens gebruikt Google op hun eigen website nog wel gewoon www voor het domein

[Gamebuster]

In een tijd van scamming en phishing lijkt mij dit niet echt wenselijk.

Wellicht dat je alleen de eigenaar van het certificaat laat zien, waardoor je direct kan zien of de website legit is en van wie het certificaat is? Safari doet dit bijv. al voor ING: De URL is volledig verborgen, alleen het certificaat is zichtbaar.

Ik weet niet precies waarom bij ING wel en bij tweakers niet; zal wel afhankelijk zijn van het type certificaat.

[Reactie gewijzigd door Gamebuster op 26 juli 2024 20:49]

[Verwijderd]

Ik weet niet precies waarom bij ING wel en bij tweakers niet; zal wel afhankelijk zijn van het type certificaat.

In tegenstelling tot Tweakers.net heeft ING een EV (extra verified) certificaat. Wellicht is dat de reden. Ik weet niet zeker of dit uiteindelijk wenselijk is. Ik kan mij voorstellen dat bedrijven als Google heel veel verschillende websites en diensten hebben, waaronder hostingdiensten waar gebruikers toch een mogelijkheid hebben om een phishing website op te zetten. Als een gebruiker dan alleen Google ziet, zonder de url van de pagina, dan kan dat alsnog voor onveilige situaties zorgen.

[OddesE]

Google kiest bij zijn certificaten en diensten gewoon hoe 'diep' het certificaat moet gaan. Het is heel simpel om example.com wel een EV certificaat te geven en someuser.example.com niet.

[mikesmit]

Ik krijg ineens een flashback naar de tijd dat e-mails virussen nog super groot waren door je “IMG_6592.JPG.exe“

Mooie tijd was dat

[CAPSLOCK2000]

Kan het zijn dat er een heel andere reden is dat Google geen URLs meer wil laten zien?

Ik ben erg tegen deze verandering, het is een domme generalisatie die niet nodig is. Als websites een domein zonder www. of m. willen dan kan dat, geen probleem. Ik heb genoeg zinloze discussies met klanten gehad om te weten dat sommige mensen hele sterke gevoelens hebben over de prefix www. Volgens sommige is het geen echte website zonder, anderen vinden het weer lelijk en overbodig.
Zo gaan we dingen versimpelen die niet versimpeld kunnen worden. Mensen maken daar een bewuste keuze in.

Prima dat Chrome ook een mening heeft in die discussie, maar ga niet achter mijn rug om je eigen regeltjes afdwingen.

De volgende stap is om ook de extensie niet meer te laten zien. Want ja, dat is maar verwarrend en slaat, zeker voor Amerikanen, meestal nergens op. .com of .net zegt in praktijk nauwelijks nog iets. Weg laten dus. Dat is geen fantasie maar iets waar echt over gepraat wordt (al weet ik niet of Google er ook bij betrokken is). Er komt steun van grote bedrijven die het maar niks vinden dat ze hun naam onder honderden domeinen moeten vastleggen. Die willen geen "bedrijf.com" en "bedrijf.net" maar gewoon "bedrijf" wereldwijd vastleggen en de hele wereld moet maar accepteren dat zij als enige recht hebben op die naam.
Zelfs dat is al mogelijk in ons huidige systeem. Je kan gewoon een TLD kopen. Dat kost een paar ton, maar voor een groot bedrijf mag dat geen bezwaar zijn.

Kan het zijn dat er een heel andere reden is dat Google geen URLs meer wil laten zien?
Bijvoorbeeld dat ze willen dat je altijd via de Google zoekmachine gaat, in plaats van handmatig URLs in te tikken? Zodat Google kan bepalen wie onder welke naam gevonden kan worden (of niet), en tegen welke prijs?

[kodak]

Google is de laatste maanden meer van dit soort wijzigingen aan het doorvoeren. Het excuus is dat het voordeel voor de gebruiker moet opleveren. De praktijk is dat google niet bewijst dat de wijziging noodzakelijk of zelf gewenst is. Tel daar bij op dat ze geen openheid geven over de afwegingen, eigen voordelen geheel verzwijgen en gebruikers er liever mee confronteren dan informeren. Dit zijn geen kenmerken van goede bedoelingen als bedrijf voor gebruikers.

[MsG]

Beetje vergezocht wat mij betreft. Ik herken me best in de aversie tegen deze sub-url's. Heel veel websites hebben nog een middeleeuwse legacy-modus om mobiele gebruikers in een hele parallele m.websitenaam.nl-variant te laten navigeren. Deel je dat met gebruikers op een desktop dan worden die ook weer geforceerd de mobiele variant te gebruiken, want 1 op 1 de m weghalen werkt bijna nooit.

Wat mij betreft gaan we gewoon allemaal over op normaal responsive. En ja als grote partij moet je dan even wat zetjes geven, dat doen ze wel vaker. Zo werd je benadeeld als je geen SSL-domein had, geen fatsoenlijke mobiele weergave, etc.

[ropstah]

Dit is machtsmisbruik en brengt consumenten en bedrijven schade aan.

Google loopt wat mij betreft naast z'n schoenen. Na het bericht van afgelopen week over het "bepalen van identiteit" is dit voor mij de druppel. Google heeft niet het recht (helaas wel inmiddels de macht) om het internet te veranderen.

Ik stap bij deze (na vele jaren trouwe Chrome user en prediker te zijn geweest) over naar een browser die open internet standaarden respecteert, teneinde een vrij en open internet te waarborgen en roep iedereen op hetzelfde te doen.

[mikesmit]

Google loopt niet naast zijn schoenen, we hebben het er allemaal zo maar gemaakt door ons volledig afhankelijk te maken van hun.

Tweakers zit overigens nog steeds vol met pro Google mensen. Ik zeg niet dat je niet pro iets mag zijn maar na wat Google de afgelopen jaren doet met hun machtsmisbruik moet je toch aan het denken zetten

[OddesE]

En dan stap je over naar Firefox? Die al lang iets soortgelijks doet met de adresbalk?

[ropstah]

Firefox? Hoe kom je daar bij? En wat bedoel je dan met soortgelijks?

[lennybrit]

Ik gebruik al jaren Google Chrome voor werk en Firefox privé. Soms ook een andere browser. Ook sinds jaren kun je met Firefox bijna alles wat je ook met Google kunt. Dat was aanvankelijk niet het geval. Heb niets tegen Google, maar stel het wel erg op prijs als er concurrentie is. En natuurlijk is het goed als Google goede input krijgt, want daar wordt echt wel naar geluisterd.

[Aardedraadje]

Dit lijkt me rijp voor misbruik. In de screenshots is al te zien hoe een blog op platform Tumblr het domein tumblr.com aangeeft, terwijl dat eigenlijk naar je dashboard zou moeten wijzen. Van toen ik nog Tumblr gebruikte, weet ik dat je op je blog zelf HTML, CSS en JS code kon zetten.

Nu geeft de browser nog de melding "not secure", maar er zullen vast platforms zijn waar inhoud op subdomeinen onder controle van potentieel kwaadwillenden is, die wel HTTPS certificaten geven voor die subdomeinen. Een phishing pagina lijkt nu alleen maar overtuigender.

[Origin64]

URLs zijn adressen. PostNL zegt toch ook niet: vanwege veiligheid geven wij niet langer het huisnummer op een pakket aan, of de postcode?

Juist als je URLs niet kan zien, zet je alleen maar meer deuren open voor misbruik, dus het slaat 2x nergens op.

Het enige correcte argument dat ik zie is "Wij van google vinden dat veel van onze gebruikers zo dom zijn dat een lange URL al te veel informatie is, waarvan ze in de war raken, dus standaard verbergen wij die. Power users kunnen de optie zelf aanzetten".

Maar dat zeggen ze niet.

[Reactie gewijzigd door Origin64 op 25 juli 2024 21:20]

[KilZone]

Ik denk eerder dat het argument is: "Wij van Google willen graag dat gebruikers niet zelf de URLs onthouden, maar zoeken via ons platform / onze zoekmachine - wij helpen u alvast een handje door enkel de zoekterm(en) in de adresbalk te tonen."

Juist als je URLs niet kan zien, zet je alleen maar meer deuren open voor misbruik, dus het slaat 2x nergens op.

Helemaal mee eens, geen speld tussen te krijgen, maar naar ik verwacht zal Google bij de volgende uitgave van Chrome URL's 'extra gaan controleren'; de marketingmachine van Google zal dit zo verwoorden dat gebruikers een nog snellere, veiligere en betere internetervaring krijgen.

Zoals nu al op de website: "Now more simple, secure, and faster than ever - with Google’s smarts built-in."

Uiteindelijk zijn al deze wijzigingen enkel bedoelt zodat Google meer controle krijgt over de internetervaring en men 'afhankelijker' wordt van de zoekmachine; waardoor er meer omzet gedraaid kan worden.

[Reactie gewijzigd door KilZone op 26 juli 2024 20:49]

[Origin64]

bij typen in de url balk zoekt chrome al automatisch op google als het adres niet resolved.
Maar ja het is idd weer 1 extra punt waarop ze reclame mensen hun hersenen in kunnen stralen. Thank god for adblockers.

[Reactie gewijzigd door Origin64 op 26 juli 2024 20:49]

[dasiro]

deze feature hebben zowat alle browsers met hun al dan niet eigen/aan te passen zoekrobot

[Origin64]

Ja, dus als search en de URL bar overal al geintegreerd zijn, wat heeft deze maatregel dan voor nut?

[sumac]

Het nut is het verdwijnen van de adresbalk, en de totale vervanging door de zoekbalk.

[Sensor55]

Dit dus.
Plus: als ik naar een commerciële site genavigeerd ben, dan staan daar vaak enorme hoeveelheden ID-info achter geplakt. Als ik dat adres wil delen, dan kan ik dat ID er nu makkelijk afslopen. In de nieuwe opzet niet meer.
Google wil maar één ding: jouw informatie.

[noobz]

Ik neem toch aan dat wanneer je op de URL balk klikt je wel gewoon de hele URL ziet?

[erikmeuk3]

Als ik dubbelklik komt het www. gedeelte er voor.
Dingen als webmail.provider.nl laat de browser wel volledig zien.
Ook de favicon wordt gefilterd en komt pas na een dubbelklik.

[Tourmaline]

Inderdaad, dubbelklik op de URL en je ziet alles gewoon weer. Big deal...
Als je kopieert, neemt hij gewoon alles mee...

[Reactie gewijzigd door Tourmaline op 26 juli 2024 20:49]

[Ayporos]

ik vind het juist handig die ID informatie, daarmee weet ik of ik daadwerkelijk de huidige pagina ga delen óf enkel de hoofd-website.

Veel websites werken met 1 unieke URL per pagina maar er zijn er ook veel die níet zo werken.. en het is verdomde handig om te kunnen zien met wat voor website je te maken hebt.. is nl. het verschil tussen iemand vertellen op een link te drukken óf iemand te moeten uitleggen hoe ze precies vanaf de hoofdpagina van die website naar de benodigde pagina komen.

[CriticalHit_NL]

ik vind het juist handig die ID informatie, daarmee weet ik of ik daadwerkelijk de huidige pagina ga delen óf enkel de hoofd-website.

Denk dat hij eerder doelt op allerlei tracking tags die soms achter een website URL worden geplakt als je deze ergens wilt delen, zodat de analytics de herkomst van een bezoeker kunnen bepalen en dat soort dingen.
Dat kan je meestal handmatig weghalen achter de URL zonder de navigatie te beïnvloeden.

Zoals dit voorbeeldje van het internet geplukt:
https://www.pixelyoursite...s/2015/12/url-builder.png

Ik heb er zelf vaak ook een hekel aan om links op die manier te delen dus ik haal het meestal ook weg, maakt het meteen ook wat overzichtelijker.

[Ayporos]

ah zo... ja okay in zo'n geval zou ik dat ook doen ja.

Wat ik soms ook wel eens doe is een youtube linkje delen... maar vaak is dat dan een filmpje welke ik aan het bekijken ben in een afspeellijst en als ik dan enkel dat filmpje wil delen dan moet ik ook de URL kortwieken... gelukkig dat youtube als URL de url van het filmpje zelf gebruikt en daarachter wat ID's plakt over de afspeellijst en niet andersom.

[Gamebuster]

Juist als je URLs niet kan zien, zet je alleen maar meer deuren open voor misbruik, dus het slaat 2x nergens op.

Kan je mij een voorbeeld geven hoe het verbergen van www. en m. een veiligheidrisico kan vormen?

Het verbergen van www. en m. wordt al een tijdje gedaan in Safari (macOS & iOS) en ik heb nog nooit klachten gezien of mogelijkheden voor misbruik.

[Reactie gewijzigd door Gamebuster op 26 juli 2024 20:49]

[Atomsk]

Een router kan een vast ingebouwd adres als www.asusrouter.com hebben dat naar de lokale inlogpagina gaat van de router. Vergeet de fabrikant dit domein ook op het internet te registreren en behouden, dan kan iemand anders het kapen, de interface nabouwen en hiermee router logingegevens verzamelen, wanneer iemand asusrouter.com intikt (zonder www).

Tot zover heeft dat niets met Google te maken. Wanneer je echter ook niet het verschil tussen wel of geen www kan zien, dan heb je een nog groter risico.

Ze zijn er echter zelf ook niet uit wat ze nu eigenlijk willen: https://www.wired.com/story/google-wants-to-kill-the-url/

[Reactie gewijzigd door Atomsk op 26 juli 2024 20:49]

[Origin64]

Dan kan ik de website www2.twitter.com registreren, er een geldig certificaat op zetten naar keuze zodat het een groen balkje heeft, en accounts stelen. Dus moet je als bedrijf straks elke mogelijke variant op je URL opkopen om dat te voorkomen.

[Reactie gewijzigd door Origin64 op 26 juli 2024 20:49]

[Gamebuster]

Dan kan ik de website www2.twitter.com registreren

Leuk bedacht, maar dat kan dus niet.

Je kan het subdomein www2 onder twitter.com niet registreren, want twitter.com (en dus automatisch alle subdomeinen onder twitter.com) is in beheer van twitter.

een geldig certificaat op zetten naar keuze zodat het een groen balkje heeft

Er zijn 2 soorten HTTPS certificaten. Het "standaard" certificaat is voor het vastleggen van een beveiligde verbinding, en het "groen balkje" certificaat voor het bewijzen van je identiteit. Groen balkje krijg je alleen na uitvoerige controle van de certificaat beheerder. Die gaan ze dus echt niet vrijgeven bij een phishing site, want die certificaten zijn alleen maar wat waard als de uitgever te vertrouwen is.

[Reactie gewijzigd door Gamebuster op 26 juli 2024 20:49]

[Origin64]

Als jij een site registreert voor een compleet ander doel dan phishing, en een certificaat krijgt, dan kun je daarmee toch mensen phishen?

[Gamebuster]

Dat kan, maar de naam van het certificaat is dan nog steeds van het bedrijf dat de phishing uitvoert. Het is lastig om te doen alsof je ING bent als de url-balk (www.ing.something.ru/ideal-inloggen.html) verborgen is en alleen het certificaat laat zien: RANDOM RUSSISCH BEDRIJF

Maargoed, dan nog steeds maakt het verschil tussen www. en geen www. niets uit, behalve dat door www. te verbergen nog net iets duidelijk is dat de URL niet klopt

[Reactie gewijzigd door Gamebuster op 26 juli 2024 20:49]

[Origin64]

Het certificaat wordt pas weergegeven als je klikt, 99,9% van de mensen zoekt alleen naar een groen slotje

[Sjoerd_r]

Bij een MITM attack waarbij een extra " w " aan " www " word toegvoegd kan het zinvol zijn om wel het hele adres te zien.

[Gamebuster]

En hoe is dat relevant wanneer de browser "www." verbergt? Dan valt het toch juist op, want "wwww." wordt niet verborgen? En wat heb je aan een MITM attack waarbij je een gebruiker wwww.ing.nl laat bezoeken ipv www.ing.nl? Als je toch al een MITM aan het doen bent, waarom dan niet de content van de site wijzigen en de URL laten zoals-ie is?

[Reactie gewijzigd door Gamebuster op 26 juli 2024 20:49]

[fastedje]

Alle subdomains horen bij hetzelfe domain en dus ook dezelde eigenaar.
Wat wel erg zo zijn is als chrome www aan het eind van een domain name weg zo filteren, bijvoorbeeld: example.
com.www wordt example.com. Dit zo oplichters ruim baan geven.

[Paultje3181]

Als ik tld twittercom registreer en vervolgens hier www.twittercom van maak, denk ik dat ik voldoende reacties krijg hoor.

[seapip]

Top level TLD registratie doe je niet zomaar, zit veel papier werk & controle achter en kost daarnaast ook nog eens veel geld

[Reactie gewijzigd door seapip op 26 juli 2024 20:49]

[Gamebuster]

Dan nog steeds maakt het 0 verschil of Chrome www. wel of niet weghaalt

[Origin64]

das waar. ff nadenken.

[Christiaan676]

Enigste beveiligingssystemen risico die ik zie is als twitter.www.com omgezet wordt naar twitter.com. Door een bug verwijderd Chrome momenteel ook www's halverwege de url. Maar geen idee of de domeinnaam ook verwijderd wordt.

[mikesmit]

De werkelijke reden van Google om de subdomeinen te verbergen moet zich nog onthullen. Maar ik heb een donkerbruin vermoeden dat de opkomst van de AMP pagina er wat mee te maken heeft

[Origin64]

AMP is een library, ik zie niet wat dit ermee te maken heeft

https://www.ampproject.org/learn/overview/

AMP is an open-source library that provides a straightforward way to create web pages that are compelling, smooth, and load near instantaneously for users. AMP pages are just web pages that you can link to and are controlled by you.

[Wulfklaue]

Even een paar linkje geven:

https://www.polemicdigital.com/google-amp-go-to-hell/

Ik heb niets tegen dat Google wilt dat websites sneller laden. Dat websites beter te doorzoeken zijn voor Google, begint mij een beetje verdacht te klinken.

Het probleem voor Google is dat meer en meer websites o.a JS verwerken in hun websites. En dit maakt geeft Google veel meer werk om het doorzoeken van websites ( men moet de JS renderen voor de feitelijke content te zien ). Gevolg is dat men veel meer server resources met gebruiken voor websites te spideren, dan als deze opgebouwd is in een "Google friendly" vorm.

Nu het issue is dat Google al een tijdje zit druk uit te oefenen om websites in hun "aanvaarde" stijl te schrijven of het zal wel eens gevolgen hebben op je ranking in Google hun Search Engine.

Gevolg is dat je ofwel een desktop + AMP versie hebt, of gewoon foert zegt en dan puur 1 AMP versie maakt want wie wilt er nu 2 verschillende versies onderhouden.

Komt er op neer dat Google meer en meer het internet probeert te controleren en iedereen wilt "zachtjes" dwingen om websites te maken dat voordelig zijn voor hun. En zolang Google Search zo een groot markt aandeel heeft, hebben ze heel wat macht.

Het verbergen van de sub domeinen is volgens mij ook zo een stap in die richting. tweakers.net en www.tweakers.net kunnen naar twee verschillende locaties gaan. Want dat zijn werkelijk 2 verschillende domain punten in je DNS. Door het samen te voegen van beide in Chrome, probeert Google eigenlijk iedereen te dwingen om in de toekomst naar een "www" loze internet te gaan.

De vraag is wat is hun voordeel om dit te doen want ze hebben HEEL WAT tegendruk op deze beslissing.

Het feit dat m.xxx.com en www.xxx.com beide verdwijnen voor 1 xxx.com versie, lijkt mij terug te vallen op gans het AMP gedoe. Nu zetten websites hun master layout op www.xxx.com en hun mobiele AMP vriendelijke op m.xxx.com. Het gevolg is dat Google beide moet doorzoeken, want de mobiele versie bevat soms minder informatie dan de master versie. Het maakt het ingewikkelder voor Google, meer resources nodig enz.

Volgens mij komt het er op neer, dat men het internet wilt omvormen naar een Google vriendelijke internet en zo miljarden uitsparen in server kosten. En met de opkomt van front-end heavy JS gebaseerde frameworks, ziet Google volgens mij de bui hangen en wilt men verhinderen dat ze te veel moeten investeren. Het is veel gemakkelijker om websites te doorzoeken als ze gestructureerd zijn in een vorm dat je op voorhand kent en dat enkel je eigen JS framework gebruikt nietwaar.

Het is de enige logica want zelf Google is nogal zwijgzaam waarom ze zo gebrand zijn om m. www. te verwijderen.

En andere voordeel is dat natuurlijk Google hun eigen cloud hosting voorzien zal worden als AMP ready, waarom tijd verspillen aan je eigen website design, maak gebruik van onze eigen cloud gebaseerde AMP oplossingen. Bla bla bla ...

Je moet blind zijn om niet te zien welke zakelijke reden erachter zitten bij Google. Het probleem is dat het een directe aanval is om de vrije design van websites. In de toekomst moeten we dus websites gaan bouwen in een vorm dat Google enkel wilt, voor hun winst redenen.

Tja ... Denk dat het tijd is dat Google opgesplitst mag worden in veel meer kleinere entiteiten. Hun macht is enorm groot, groter dan veel gewone gebruikers denken. En zo lang iedereen aan Google producten zit, kunnen ze langzaam veel meer van deze zaken pushen. Klinkt nogal MS IE6.0 achtig met hun eigen standaarden nietwaar...

[mr.paaJ]

off topic verder, maar dit leest als een googletranslatebericht.

[Wulfklaue]

Best mogelijk ... Ik woon al jaren niet meer in België, zo dus men Nederlands begint nogal "roestig" te worden. Komt er van als je jaren non stop Engels spreekt

[Origin64]

Interessant, bedankt!

[mikesmit]

De Library ja. Maar wie host de AMP versies van websites? Is het zo ver gezocht dat Google wil dat je het domein niet meer ziet zodat ze je altijd op de AMP versie kunnen houden zodat enkel Google nog verdient aan AMP?

[lenwar]

Een iets te heftige reactie wat mij betreft.

Bij het bewerken van de adresbalktekst verschijnt het subdomein wel en de optie is nog te togglen.

Het gaat duidelijk om een cosmetische verandering voor wat er in de adresbalk staat als deze niet geactiveerd is. Als je dus de adresbalk aanklikt om iets in te tikken staat het er dus nog wel. Vooralsnog in elk geval, maar we kunnen niet in de toekomst kijken.

Even los van het feit dat ik het zelf ook niet zo'n goed idee vindt, kan je je natuurlijk wel daadwerkelijk afvragen wat de weergave van het www-stukje nog toevoegt. Een aanzienlijk deel van de websites heeft het zelf als verwijderd (als enkele voorbeelden: tweakers.net, nu.nl, nos.nl). Maakt het onder aan de streep nou echt zoveel uit of je op www.appelflap.nl, m.appelflap.nl of appelflap.nl bent? Zolang je pagina goed weergegeven wordt is het toch ok?

En nog los daarvan. Als men het echt onoverkomelijk vindt, gaan mensen vanzelf wel een andere browser gebruiken.

Edit: typo

[Reactie gewijzigd door lenwar op 26 juli 2024 20:49]

[OddesE]

Het gaat duidelijk om een cosmetische verandering voor wat er in de adresbalk staat als deze niet geactiveerd is.

Helemaal mee eens. Op een mobieltje zie je anders

https://www.tweakers.n....

in plaats van

tweakers.net/nieuws/14...

Het idee is dus denk ik om te zorgen dat je op een klein scherm zoveel mogelijk relevante info toont.

[Origin64]

zolang je er van uit gaat dat de pagina die goed wordt weergegeven ook de pagina is die je wilde hebben en geen phishing, dan is het prima. Maar het lijkt me makkelijker om te phishen als browsers niet de hele URL weergeven. Technisch weet ik niet hoe het precies zit met die www prefix en DNS servers, dit is meer een gevoel. Ik weet wel redelijk zeker dat ik weleens heb meegemaakt dat een adres met www. ervoor naar een compleet andere site ging dan hetzelfde zonder www. ervoor. Misschien slecht geconfigureerde website, of gehackt om naar een ander adres door te verwijzen met of zonder www.?

[Reactie gewijzigd door Origin64 op 26 juli 2024 20:49]

[kristofv]

www is ook maar een standaard subdomein, aan te maken via een A record (ip -> hostname) of CNAME (hostname-> hostname) op je DNS.

Je kan dit dus laten redirecten naar eender wat in principe.

[lenwar]

Het gaat hier nadrukkelijk om het al-dan-niet weergeven van de twee meestgebruikte subdomains, www en m.

Of appelflap.nl of www.appelflap.nl de juiste site weergeven maakt phishing niet moeilijker of makkelijker. Het gaat denk ik pas een andere situatie worden als alle subdomains wordt weggelaten.

Als bijvoorbeeld mijnbetrouwbarewebsite.appelflap.nl en phishingwebsite.appelflap.nl beiden als appelflap.nl worden weergegeven, dan gaat het wel tricky worden.

[Nutral]

Het is misschien eerder dat er op een postpakket niet meer nederland staat. omdat het toch onbeduidend is. Al vind ik M eigenlijk wel belangrijk om te laten staan.

[Origin64]

www is ook belangrijk, er zijn gevallen waarin een adres met www. ervoor ergens anders heen leidt dan hetzelfde adres zonder www.

[AtlAntA]

Er zijn ook nog zat adressen die www2 gebruiken. Wordt dat ook weg gelaten?

[erikmeuk3]

Nee

[ViperXL]

Niet alleen dat, straks gaat Google de adresbalk compleet verwijderen omdat men denkt dat ze met Google Search als startpagina overal kunnen komen dus dat niet nodig hebben.

[Rabb]

Dat hebben ze al gedaan. Niemand gebruikt de omni bar als adresbalk. Je typt de naam in van de website, en klikt binnen google op de juiste link.

[Jorgen]

O ja? Het is dat auto-aanvullen aanstaat, maar anders typte ik toch nog steeds alles in.
Alleen hele lange adressen met subfora wil ik wel eens "via Google" doen, maar voor de rest is het zelf de url typen, al dan niet versneld met auto-aanvullen.

[stresstak]

De gewone mens: 'Waarom zou ik het houterig gaan intikken als ik het kan aanklikken zonder kans op typefouten.. ?''

[heggico]

Erger nog, ik zie vaak dat ze dan eerst "google" tikken en dan pas zoeken...

[87Dave]

Dat zal inderdaad de onderliggende bedoeling zijn. Alles via hun search dwingen. Maar dat zal wel weer een megaboete van de EU opleveren omdat dat puur machtsmisbruik zal zijn.

[ViperXL]

En betalen ze uiteraard gewoon weer de boete want qua kosten/baten kan het makkelijk uit

[lenwar]

Nou, zo werkt het niet
Ze krijgen een boete en daarna moeten ze alsnog hetgeen wat ze overtreden rechtbreien, anders komt er nog een boete of gaat de EU andere juridische maatregelen nemen.

[Origin64]

En hoe ga ik dan aan Chrome gebruikers uitleggen waar ze de remote control tool van de helpdesk waar ik werk kunnen downloaden? Typ het maar in google? Lekker bezig, Google...Valt helemaal niet op hoor....

[Reactie gewijzigd door Origin64 op 26 juli 2024 20:49]

[Bart R]

Hyperlink het in een email, je red je er maar mee

[Origin64]

Ja als het kan dan stuur ik het via skype of mail, maar wat nu als iemand niet aan kan melden...

[zwartbaard]

Gaat wel goed als de klant een mail probleem heeft

[Croga]

Hyperlink het in een email, je red je er maar mee

En hoe wil je die hyperlink kopieren als je gaan adresbalk hebt? :-p

[Loggedinasroot]

*Klik*

[stresstak]

Hyperlink het in een email, je red je er maar mee

Hyperlink het in een phishing mail. Criminelen bedenken vast wel wat.

[biglia]

omdat men denkt dat ze met Google Search als startpagina overal kunnen komen

Dat gevoel wordt ook versterkt omdat Google op die manier ook vaak wordt gebruikt. Er zijn bij Google nu al 2060000000 requests per maand op de zoekterm "facebook". Dus ja, mensen gebruiken Google om enkel naar Facebook te surfen. Rechtstreeks facebook.com intypen wordt al niet meer gedaan. Misschien is er per generatie al een verschil te zien in het gebruik van Internet.

[Reactie gewijzigd door biglia op 26 juli 2024 20:49]

[HansvDr]

Fb + ctrl + enter

Sneller dan google

[hayashikaiji]

De vraag is natuurlijk of volledige URL onnodig is voor meeste mensen. In dit geval zie ik wel waarom Chrome dit doet, maar vind het zelf niet fijn en niet veel helpen. We hebben het immers over 2 of 4 symbolen.

[KopjeThee]

Het wordt heel lastig gemaakt om te controleren op welk adres je precies bent. Het is niet uitgesloten deze verwarring door kwaadwillenden kan worden misbruikt.

[sdk1985]

URLs zijn adressen. PostNL zegt toch ook niet: vanwege veiligheid geven wij niet langer het huisnummer op een pakket aan, of de postcode?

Juist als je URLs niet kan zien, zet je alleen maar meer deuren open voor misbruik, dus het slaat 2x nergens op.

Het enige correcte argument dat ik zie is "Wij van google vinden dat veel van onze gebruikers zo dom zijn dat een lange URL al te veel informatie is, waarvan ze in de war raken, dus standaard verbergen wij die. Power users kunnen de optie zelf aanzetten".

Maar dat zeggen ze niet.

Probleem is dat in de praktijk voor de gebruiker www synoniem is aan non-www. Echter in de technische implementatie is dat niet zo en is www echt een sub-domein van het hoofddomein. De meeste hosting providers lossen dit op door www standaard hetzelfde A-record, of zelfs een alias, te geven.

An sich zou het internet er niet slechter van worden als we met zijn allen afspreken om de primaire website op het hoofddomein te installeren in plaats van op www. Wellicht wil Google hier naar toe. Persoonlijk heb ik daar geen bezwaren tegen. Lost een hoop problemen op. Scheelt bij SSL ook weer een forwarder .

Zelf heb ik tot heden overigens ook de voorkeur voor www, maar ik ben dan ook niet anders gewend.

[Reactie gewijzigd door sdk1985 op 26 juli 2024 20:49]

[aex351]

Dit is een trend dat al een langere tijd gaande is. "http" werd ook al niet meer weergeven. "https" nog wel. Hetzelfde geldt voor Firefox. Nu strippen ze dus 'triviale" subdomeinen. Dit soort dingen gaan alleen werken wanneer websites, webapplicaties worden met een enkele beginpunt.

[blinchik]

Dit is inderdaad een zeer zorgelijke evolutie. Ja, gebruikers zijn dom, maar als de producten die ze gebruiken ook nog eens slechter worden, dan zal het er niet beter op worden.

Hopelijk kan dit via een parameter makkelijk teruggedraaid worden.

[Verwijderd]

Als een browser niet bevalt ga je toch een andere gebruiken? Of zelf een browser gaan maken.

[blinchik]

Ja, maar voor de rest werkte Chrome wel fijn. Firefox werkte vrij traag maar ik heb begrepen dat dit nu wel een stuk versneld is met de nieuwe builds. Toch inderdaad eens probleren.

[Vayra]

Tja... dat is een keuze van de grote massa beledigen met de waarheid of een niche van tech adepten beledigen met een politiek correcte omschrijving.

Lijkt me geen lastige keuze, als je het vanuit Google bekijkt. Het probleem wat je aankaart is niet Google's probleem, maar dat van de mensen zelf. Verder is het een feit dat er een overdaad aan informatie op je af komt bij het gebruik van internet, dus versimpeling is in die zin niet eens zo slecht, lijkt me.

[Reactie gewijzigd door Vayra op 26 juli 2024 20:49]

[iAR]

Op zich halen ze alleen www. en m. weg he? Vergelijkbaar met adressen afkorten als "Kerkstr" ipv "Kerkstraat". Het is niet zo dat adressen zo worden: bankieren.ing.nl; dat zou wel kwalijker zijn.

Dat langere urls afgekort worden is omdat je voor bijvoorbeeld internetbankieren vaak moet checken of het wel rabobank.nl is. dan helpt www.m.rabobank.nl/intern$...html/75839625478325674238 niet echt: rabobank.nl is dan voldoende.

[Origin64]

Dat er steeds meer prefixes zullen worden weggelaten lijkt me logisch, wat maakt het de meeste chrome gebruikers nou uit of je op bankieren.ing.nl of shadyprefix.ing.nl zit? Als er maar een groen slotje staat.

[Reactie gewijzigd door Origin64 op 26 juli 2024 20:49]

[josttie]

Eensch. Het eerste wat ik bij safari merk is dat de website gelijk "mooi" wordt weggestopt. En dat maakt het gelijk voor mij een gedrocht van een browser, vaak zat moet ik met de URL knoeien, bijvoorbeeld jira dat je even simpel ticket nummer wilt veranderen. Gelukkig toen ik een jaar moest werken op een Mac dat ik Firefox kon installeren, dus geen idee of het in of uit te schakelen was, maar ik voelde wel vanaf moment 1 dat ik een stuk controle mistte en gelijk van safari af moest. Ik ben het nooit met chromes geheugenmanagement eens geweest, dus altijd bij Firefox gebleven op Windows, maar dit is wel iets wat bij mij in het verkeerde keelgat zou schieten: minder controle. Geef mij die URL, laat mij ermee doen wat ik wil en oprukken met de huismoeder visie (want die heeft het toch niet nodig)

[josttie]

Of je kan dat gewoon... Als ik even in de URL een nummertje moet veranderen gaat dat sneller dan zoeken en rondklikken. Gaat zelfs sneller dan een shortcut instellen als zoekterm. Dus geen probleem met de tooling, het geeft gewoon meer controle om af en toe de URL te veranderen. Ook bij sommige apps kan je geen URL plaatsen, als iemand een YouTube wil linken is het vaak ?v=heoebe en hoe meer de browser verstopt, hoe moeilijker dit soort dingen openen wordt.

[scorpie]

Google heeft kort geleden al eerder te kennen gegeven dat het de url in de toekomst niet langer wil weergeven in Chrome. Adressen zouden te ingewikkeld geworden zijn, wat gebruikers kan verwarren en ze kwetsbaar maakt voor door kwaadwillende gemanipuleerd url's.

"Security through obscurity" maar dan clientside? Lijkt me niet echt wenselijk. Ik gebruik juist de hover functie van links om te zien wat die link precies opent, als je alleen maar knoppen krijgt zonder dat je weet wat het doet gaan we denk ik heel gauw terug naar de ontelbare askbar achtige IE-6 taferelen..

[Reactie gewijzigd door scorpie op 26 juli 2024 20:49]

[ZpAz]

Die hover is heel simpel te manipuleren. Op de "href" tag van de link die je aanklikt stop je de url. Met maar met JS ga je op de onclick de gebruiker ergens anders heen sturen.

[mrdemc]

En ook exact hetgeen Google toepast op z’n advertentie zoekresultaten als je over die links heen hovert waardoor je toch naar doubleclick gaat.

[scorpie]

True, sad but very true.

[mschol]

zijn de developers bij google helemaal het concept van subdomeinen vergeten ofzo?
zoals ook aangehaald in de tekst: domein.tld en www.domein.tld kunnen naar totaal andere sites verwijzen, ik doe dat zelf bewust bij mijn eigen domein.
Deze wijziging levert alleen maar onduidelijkheid op en zet ook de deur open naar zwaar misbruik.

Net als het uitfaseren van het slotje, het van de groene balk bij EV SSL certificaten en het verwijderen van het protocool vraag ik mij serieus af of er nog wel wordt nagedacht bij die developers over usability en user experience..
chrome holt hard achteruit op deze manier

[Reactie gewijzigd door mschol op 26 juli 2024 20:49]

[White Feather]

Wat is de reden dat je domein.tld maar iets anders verwijst dan www.domein.tld?

[WhatsappHack]

Ik vraag me hetzelfde af. Veel mensen snappen het verschil niet, sommigen denken zelfs dat “www.” nog altijd verplicht voor de URL moet; al benoem je het niet: ze zetten het er gewoon voor. Weer anderen gaan er vanuit dat met en zonder www. hetzelfde is omdat 99.9% van de sites nou eenmaal zo werken.

Waarom je dan tegendraads zou gaan doen...?

[sdk1985]

Ik vraag me hetzelfde af. Veel mensen snappen het verschil niet, sommigen denken zelfs dat “www.” nog altijd verplicht voor de URL moet; al benoem je het niet: ze zetten het er gewoon voor. Weer anderen gaan er vanuit dat met en zonder www. hetzelfde is omdat 99.9% van de sites nou eenmaal zo werken.

Waarom je dan tegendraads zou gaan doen...?

Het moet er ook verplicht voor, tenzij de website bouwer/hoster de zaakjes netjes hebben geimplementeerd. Ik kwam vorige week nog een semi publieke website tegen waarbij de non www>www gewoon niet was geregeld:

quote: http://shl-groep.nl

The DNS name does not exist

www is echt een subdomein en je kunt op www.domein.nl iets heel anders plaatsen dan domein.nl.

Ik denk dat momenteel 9 van de 10 websites www als prefix gebruiken. Op het moment dat www niet meer wordt weergegeven zou dat op termijn weleens om kunnen draaien.

[Reactie gewijzigd door sdk1985 op 26 juli 2024 20:49]

[Tokkes]

Mijn domein.tld DNS A-record hoeft niet per se naar mijn webserver te wijzen. (heb ook geen website, maar goed ), terwijl je dat van een www.domein.tld record _wel_ verwacht.

[mschol]

Wat is de reden dat je domein.tld maar iets anders verwijst dan www.domein.tld?

omdat ik beide naar een andere site en/of dienst laat verwijzen, beide voor een ander doel..

[kristofv]

Vroeger was het ietwat standaard om je mailserver onder domein.tld te draaien , indien er geen mx records aanwezig zijn zal ook nog steeds automatisch op domein.tld gekeken worden of daar soms een mailserver zit te luisteren.

[Origin64]

Er wordt nagedacht over user experience voor de overgrote meerderheid van de chrome gebruikers die nu chrome de grootste browser is over het algemeen geen hol van computers snappen. Het probleem is dat hun user experience ten koste van security gaat.

[KeesAlderlieste]

even mierenn*ken: is www wel een subdomein of gewoon een hostnaam? Het staat tenslotte als A-record in de dns. bij www.subdomein.domein.nl kan je pas van een subdomein spreken, maar www is hier dan toe weer de hostnaam.

[Navi]

example.com is een domein
www.example.com is in principe al een subdomein.

Zoals je hier ziet stuit deze aanpassing op veel weerstand, maar opzich hebben ze een punt, overal www ervoor, waarom eigenlijk, toon de hoofdsite gewoon op example.com.

Is nog niet eens zo'n gek idee, dat www zal wel historisch zo gegroeid zijn.

m.example.com, tja, die zou je kunnen laten, of de detectie van apparaten verbeteren zodat ook dat hele subdomein niet meer nodig is.

Ik denk dat dit een gevalletje apple die de cdrom speler weg wil laten is, iedereen brult hard, maar jaren later is het normaal en zit hij nergens meer in.

[pennywiser]

Niet in principe, het *is een subdomein. Is iets van voor het shared hosting tijdperk, maar niet altijd onnodig. Zie FQDN.

[Sfynx]

Zoals je hier ziet stuit deze aanpassing op veel weerstand, maar opzich hebben ze een punt, overal www ervoor, waarom eigenlijk, toon de hoofdsite gewoon op example.com.

Is nog niet eens zo'n gek idee, dat www zal wel historisch zo gegroeid zijn.

Door www. in het subdomein te zetten zie je puur aan de FQDN al wat het doel is ervan, net zoals je ftp, mail, news, etc. hebt. Het internet bestaat niet alleen maar uit websites. Uiteraard zal de extra context van een http(s):// URL het ook wel duidelijk maken dat het een website is, maar je moet dingen zo duidelijk mogelijk houden. De historische beslissing om een domeinnaam naar functionaliteit op te knippen in subdomeinen vind ik dus niet zozeer een slechte.

[pennywiser]

Verkeerd gedacht. Grappig dat er nu na zoveel jaar publiek internet mensen zijn die o-ve-ral www voor denken als reflex.