Google begint in Chrome 86 test met verbergen van prefixes in url-balk

Google begint in de aankomende versie van Chrome met een test waarbij alleen nog maar de domeinnaam wordt getoond in de url-balk. Het volledige domein, dus ook prefixes als www, verdwijnen dan. Wel komt er een menuoptie om die info alsnog te tonen.

Google begint met een experiment in Chrome 86, die voor oktober dit jaar gepland staat. Een kleine groep gebruikers krijgt in die versie van de browser alleen nog de domeinnaam te zien. Prefixes zoals https en www worden daarbij niet langer getoond. Ook interne url's en anchors worden niet meer automatisch getoond.

Gebruikers kunnen wel met hun muis over de url-balk gaan om alsnog het hele domein te zien. Daarnaast komt er een optie in het Chrome-menu om standaard alsnog de hele domeinnaam te tonen als gebruikers dat willen.

Google zegt zelf dat het browsen daarmee veiliger wil maken. Met enkel het hoofddomein in de url-balk zouden gespoofte en phishingdomeinen makkelijker te spotten zijn. Het bedrijf verwijst daarbij naar een studie die het zelf uitvoerde. Daaruit zou blijken dat veel gebruikers domeinen vertrouwen als daar ergens de naam van de gespoofte dienst in wordt genoemd, ook als dat bijvoorbeeld als prefix of subdomein wordt gebruikt. Door alleen het hoofdgedeelte van de url nog te tonen zouden gebruikers makkelijker zien dat het om een nepdomein gaat. Met de test wil Google kijken hoe gebruikers reageren op de nieuwe url-implementatie.

De functie wordt voor het eerst getest onder een beperkte groep gebruikers. Ook niet-geselecteerde gebruikers kunnen de feature oproepen door #omnibox-ui-reveal-steady-state-url-path-query-and-ref-on-hover en #omnibox-ui-sometimes-elide-to-registrable-domain handmatig aan chrome://flags toe te voegen.

Het is niet de eerste keer dat Google denkt over het verbergen van dergelijke informatie. In Chrome 79 werd het tonen van prefixes al helemaal verwijderd, al kwam dat later toch weer terug met een toggle.

Reacties (134)

[84hannes]

Er mag weinig twijfel zijn dat Google het liefst het hele internet zou beheren: hun browser, hun zoekmachine, hun server (AMP) en geen universele methode om buiten Google op webpagina’s te delen (url’s). Dat gezegd hebbende is de URL een complex ding voor mensen die niet eens weten wat een protocol of een subdomein is. Regelmatig hoor ik mensen de punt tussen wwww en het domein weglaten, bijvoorbeeld wwwfbto.nl (was ooit in hun reclame). Dan heb je duidelijk de significantie van de punt niet begrepen. Dus uit veiligheidsoverwegingen snap ik deze stap wel, al hadden ze dat ook anders kunnen oplossen. Het domein vet weergeven en misschien zelfs een andere achtergrondkleur geven zou waarschijnlijk dezelfde veiligheid bieden.

[Reactie gewijzigd door 84hannes op 27 juli 2024 11:18]

[sus]

Regelmatig hoor ik mensen de punt tussen wwww en het domein weglaten, bijvoorbeeld wwwfbto.nl (was ooit in hun reclame).

Aargh, zooooo storend. Of, ook veel voorkomend, het verkeerd noemen van een mailadres, en dan juist *met* www. ([e-mail]) en er specifiek bij vertellen dat alles kleine letters zijn.

[MarcoDaz]

Sorry, maar *@www.*.* heb ik echt nog nooit gehoord en ik moet dagelijks e-mailadressen aanhoren van klanten en collega's. Kan aan mij liggen natuurlijk.

[Raziel]

Dan heb je mijn vader nog nooit ontmoet!

[Username3457829]

Of mijn vader! Die probeert met zijn outlook in te loggen op gmail en heeft het na een kwartier nog niet door en wordt boos en alles. Die weet helemaal niet wat een url adres is. Als je hem vraagt ga naar google, dan vult ie het voor je in in het vakje waar je je email adres invoert. Die heeft letterlijk googlesearches gebookmarkt ipv websites (al een wonder hoe die dat weet te doen). Die kan niet eens naar Google zelf navigeren zonder de bookmark aan te klikken. Of dat je in de url balk gewoon direct je zoekopdracht in kunt voeren, hij vergeet het altijd.. letterlijk A L T I J D. Al vertel je het 100x ...

[84hannes]

en er specifiek bij vertellen dat alles kleine letters zijn.

Precies dat. Ik weet dat de meeste servers op een unixachtig systeem draaien, dat unix doorgaans een hoofdlettergevoelig bestandssysteem gebruikt en dat na de eerste / tot de eerste ?, # etc. vaak een map op het bestandssysteem is, dus ik snap het als het tweede deel van de URL hoofdlettergevoelig is, terwijl het eerste deel dat nooit is en het derde deel (de query?) waarschijnlijk ook implementatieafhankelijk is... maar dat is toch niet uit te leggen?

[Reactie gewijzigd door 84hannes op 27 juli 2024 11:18]

[freaky]

E-mailadressen en domeinen zijn niet case sensitive.

[bassekeNL]

Alles voor de @ kan case sensitive zijn in een domeinnaam. Het hang van de server af:

https://tools.ietf.org/html/rfc5321#section-2.4

Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
and extension name keywords) are not case sensitive, with the sole
exception in this specification of a mailbox local-part

[witchdoc]

Niert gehaal onlogisch aangezien email adressen case sensitive (kunnen) zijn!
Ok, de domeinnaam zelf niet, maar het gedeelte voor de @ wel dus.

[mosm]

Dat kan, theoretisch. Praktisch gezien is het altijd case insensitive. Case sensitive email adressen is bad practice en geen gangbaar mail systeem heeft dat.

[84hannes]

e-mailadressen zijn (een vorm van) gebruikersnamen en die zijn ook zelden case sensitive. Ik kan me echter tijden herinneren waarin de ING wel case-sensitive gebuikersnamen had, maar wachtwoorden case insensitive waren . Mijn mobiele toetsenbord maakte de eerste letter van mijn inlognaam altijd een hoofdletter, het heeft me redelijk wat tijd gekost om er achter te komen waarom ik niet kon inloggen (omdat de meeste mensen apps installeren was dit probleem waarschijnlijk onder de radar gebleven).

[Ayporos]

Ik heb toch menig account waar mijn gebruikersnaam case-sensitive is.. en dat is vrij irritant wanneer je niet meer precies weet wélke sites dat zijn.

Ik ben overigens nog nooit een mailserver tegengekomen met case-sensitive adressen.
Heb al jaren geen mailserver meer gerunt/gemanaged dus heb geen idee welke servers dat wel/niet ondersteunen en/of opties hebben om het aan/uit te schakelen, wellicht weet een van jullie daar meer van?

[Jan-E]

Piet Beertema, godfatherof.nl, heeft of had wel degelijk een Case Sensitive mail adres voor het @cwi.nl
https://www.webhostingtal...ost343988.html#post343988

[Reactie gewijzigd door Jan-E op 27 juli 2024 11:18]

[sus]

Ik heb nog nooit gehad dat dat bij email het geval is. Een URL kan wel degelijk, zeker bij een unix/linux host komt dat voor. Maar met email echt nog niet 1x. Regelmatig gezien dat mensen ter verduidelijking hun voor- en achternaam even met een hoofdletter op bv een visitekaartje hebben staan, maar ik vul standaard alles in kleine letters in.

[Raymond Deen]

Bit.ly is een voorbeeld van een hoofdlettergevoelige website.
Tikte vorige week een url over en gebruikte daar niet dezelfde hoofd- en kleine letter combi bij; toen zat ik ineens op een website die je niet op je werk tijdens een presentatie wilt laten zien, zeg maar...

[sus]

Dat zeg ik, een URL. Maar een mailadres? Nope

[Shaflic]

bit.ly
Bit.ly
bIt.ly
biT.ly

Komt bij mij toch allemaal op dezelfde site terecht. Hoe bedoel je dat de website case sensitive is?

Of bedoel je de pagina's, dus na /
bit.ly/ranDomLink
bit.ly/raNdomliNk

De pagina's zijn inderdaad casesensitive en kunnen dus naar een andere pagina leiden, maar het domein zelf niet.

[Raymond Deen]

De pagina's inderdaad.
Mijn reactie was trouwens bedoeld als ondersteuning van de reactie van @sus .

[Gubbel]

Ik heb collega's die nog altijd www. communiceren voor onze website, gelukkig maar dat die redirect naar non-www er gewoon in zit.

Ook communiceren ze domeinen die we voor klanten moeten opzetten die letterlijk onmogelijk zijn terwijl we ze er zo vaak op aanspreken .

Domeinen zijn echt heel lastig voor veel mensen.

[don spike]

Regelmatig hoor ik mensen de punt tussen wwww en het domein weglaten, bijvoorbeeld wwwfbto.nl (was ooit in hun reclame).

Ik luister zelf veel Duitse radio en podcast, om zo ook de taal een beetje bij te blijven. En het valt mij altijd op dat ze in Duitsland nooit de punt uitspreken, maar deze gewoon weglaten.
In jouw voorbeeld is het dan www fbto nl. Wel met een hele korte tussenpozen uitgesproken.

Weet niet of Duitsers ook meer bewust zijn van de punt en de functie, maar gezien ze het nooit uitspreken, en zonder je het domein niet gaat bereiken, denk ik dat de doorsnee Duitser dit dan wel goed genoeg begrijp?

[84hannes]

Alle punten weglaten vind ik zelf ook duidelijker dan soms wel en soms niet punten weglaten.

[TheVivaldi]

Ik hoor Duitsers het juist wel altijd uitspreken. Verschilt denk ik per persoon.

[Selmer]

De goedwerkende GIF ter demonstratie van de verborgen subdomeinen in Chrome 86:

https://i1.wp.com/media.g...if?resize=592%2C254&ssl=1

[Mavamaarten]

Ik vind het wel bizar dat uiteindelijk het subdomein ("en", in dit geval) wel gewoon nog getoond blijft?

[aeterno]

Lijkt me toch wel wenselijk, als ze ooit die subdomeinen gaan strippen dan heb ik op mijn werk een grandioos probleem.

We werken met 1 subdomein per klant, als die opeens allemaal de illusie hebben dat ze op het hoofd domein zitten, en dus ook koppig naar het hoofd domein gaan navigeren, dan staat de telefoon hier roodgloeiend. (gelukkig zitten onze gebruikers niet op test branches van browsers, maar even vooruit kijkend als dit ooit productie status krijgt)

Het is wel wat tegenstrijdig met wat het artikel van tweakers beweert. Jammer genoeg geeft het chromium dev blog ook niet echt informatie over wat ze nou eigenlijk van plan zijn te strippen, en onder welke voorwaarden.

[Mavamaarten]

Wenselijk is dat absoluut. Maar dan klopt het toch niet met wat ze in het artikel schrijven?

[aeterno]

De bewoording in het tweakers artikel was inderdaad onjuist. Aangezien ze alle verwijzingen naar subdomein nu gestript hebben zijn ze daar zelf ook achter

[kamerplant]

Het is vast wenselijk, maar dan klopt dit hele artikel toch niet?

[RAMillu]

Maar was niet een van de redenen hier voor dat er mensen waren die links als Google,xyz,com gingen maken om mensen te misleiden. Dat kan nu dus nog steeds

[LNDN]

Je stript het niet, je laat het alleen niet zien in de URL bar. Je filters zullen nog prima werken. Het is gewoon een esthetische verandering met een achterliggend doel.

[ThatGuyAndy]

Naar mijn mening maakt dit het uitzicht gewoon cleaner, ik zie er geen nadeel in zolang je makkelijk nog steeds de volledige url kan zien zoals ze nu hebben gedaan.

[SuperDre]

Ik zie niet in hoe je met alleen het hoofddomein te tonen je makkelijker phishing of spoofing kunt detecteren. Laat toch gewoon die hele URL zien.. Wordt er een beetje moe van dat anderen iets gaan beslissen omdat zij vinden dat het er dan netter uit ziet (want het is gewoon voornamelijk een design kwestie).

[Blokker_1999]

example.com/secure.jouwbank.nl/hele_lange_string
jouwbank.nl.example.com/lange_string

[Reactie gewijzigd door Blokker_1999 op 27 juli 2024 11:18]

[MarcoDaz]

Als ze iets zouden moeten veranderen zou dat de leesrichting van URL's moeten zijn. ipv internetbankieren.rabobank.nl (voorbeeld) zou nl.rabobank.internetbankieren veel logischer zijn voor leken en zijn fake sites veel makkelijker te herkennen, maar dat is dan helaas weer niet hoe het werkt.

[JAVE]

Dat is net zo logisch als deze datumnotitie 20200814.
Voor 'normale' mensen staat wat ze willen weten dan echter op de laatste plaats.
Je wil niet weten welk jaar het is (tenzij je een tijdreiziger bent, is dat het minst belangrijke deel van de datum). Meestal weet je ook wel welke maand het is, maar welke dag van de maand is het meest informatieve stukje.

Zo ook voor de URL.
Je wil niet weten dat je een nederlandse site bezoekt (je bent toch een nederlander, bij een nederlandse bank), van de rabobank (Dat wil je wel weten, als je niet bij de rabobank zit, zit je blijkbaar fout), en wel de internetbankieren pagina (Want je wil internetbankieren).

Wat is het belangrijkste: Je wilt internetbankieren, bij de rabobank, in nederland. Hee, precies de volgorde van de huidige URLs

[Daoka]

Dat is net zo logisch als deze datumnotitie 20200814.

Deze datumnotitie heeft juist een heel handige functie. Hierdoor zorg je dat je de sortering op volgorde heb en niet 1 januari - 1 februari - 1 maart..... 2 januari - 2 februari....

Ja sommige dingen zoals excel en databases kan er gewoon mee omgaan. Maar windows bestandsnamen bijvoorbeeld niet. Dan is die sortering heel handig.

[CEx]

Ja sortering in simpele software kan mogelijk gemaakt worden door de datum als een getal te sorteren.

Maar je maakt het lastiger voor mensen en in feite ben je het werk aan het doen voor de programmeur. Niet sommige zaken kunnen er mee omgaan, bijna alle. Inclusief windows verkenner of ieder andere file explorer sinds windows 3.1.

Ze als getal weergeven heeft nog een ander praktisch probleem, ik kan toevallig mijn factuurnummer in de bestandsnaam hebben staan (of welk nummer ook) en dat kan ook 20200815 zijn. Hoe onderscheid ik dat van een datum? Of wil je die logica ook in naamgeving gaan stoppen?

[Ablaze]

Sowieso irritant om datums in factuurnamen te stoppen.
Een factuur moet gewoon het factuurnummer in de naam hebben, zodat je dat makkelijk kunt plakken in een boekhoudprogramma.

Verder is de notatie yyy-mm-dd een wereldwijde standaard (ISO 8601). Het zou fantastisch zijn als iedereen niet zo eigenwijs deed (de Amerikanen doen de maand eerst, sommige Europeanen de dag eerst, anderen het jaar eerst) en gewoon die standaard aanhield. Net als de standaard voor decimaal scheidingstekens en duizendtallen. Scheelt een heel gedoe, vooral als je een internationaal bedrijf bent of überhaupt internationaal met anderen samenwerkt.

Los van dit alles is de datumnotatie sowieso onhandig; waarom drie verschillende getallen gebruiken die ook nog eens allemaal op een inconsequente manier bij een ander getal overflowen? Beter gewoon Epoch timestamps gebruiken

[Reactie gewijzigd door Ablaze op 27 juli 2024 11:18]

[Daoka]

Ik zal niet zeggen dat alle software er mee om kan gaan. Tenminste het zal er geen datum uit halen. Al is het natuurlijk gewoon mogelijk. Controleer of er 8 getallen zijn. Controleer of getal 5 en 6 niet boven de 12 uitkomen en controleer of getal 7 en 8 noiet boven de 31 uitkomt. Daar dan de getal om door in de volgorde van de getallen 78561234 te gebruiken en zet er een streep tussen 2e en 3e getal en 4e en 5e getal. En je heb je normale datum. Of van te voren al strepen zetten zoals 2020-08-15. Dit omdraaien heb ik ook wel eens gedaan voor me eigen mini programma.

Maar over het algemeen zal een programma dit niet doen (al kan dit natuurlijk wel zolang er maar goede afspraken gemaakt zijn tussen de gebruiker en programmeur). Maar de zal meestal gewoon een normale datum uit de systeem halen en die in de database zetten waardoor jij je bestanden gewoon kan noemen zoals jij dat wilt. Dus zoals die makkelijk voor Windows te sorteren is om bestandsnaam. Daarom verwacht ik niet dat de meeste programma's dit niet gebruiken maar hier toch geen problemen mee hebben.

Dan je factuurnummer probleem. Over het algemeen zet je de facturen niet in dezelfde map als andere dingen dus dat zou al niet gauw verkeerd gaan. Maar je kan dan ook de bestandsnaam "factuur 20200815", "factuur 20204637", "offerte 20200815" en "vakantiefoto's 20200815" om even wat te noemen. Dan is alles bij elkaar gesorteerd qua soort bestand, gebruik de factuur gewone nummers en de rest datum nummers of gewone nummers (net wat je wil) en heb je alles gesorteerd.

[JAVE]

Ik ben geen computer; ik kan dus heel makkelijk dingen als '1 januari' parsen. Als er 20200101 staat moet ik dat eerst opdelen in 2020 01 01, en dan de eerste 01 converteren naar januari.

Als ik mijn gedrag moet aanpassen aan een programma, is dat programma niet goed geschreven. (Zeg ik als programmeur die zich heeft mogen uitleven op het Y2K probleem, en dus waarschijnlijk meer met datums in al hun kromme varianten heeft gewerkt dan menig ander )

Windows kan trouwens gewoon omgaan met datums in bestandsnamen, alleen sorteert het anders dan jij zou willen

[Boschjesman]

20200815 is overal hetzelfde, '2 januari' snapt een Duitse of Engelse parser niet.

[JAVE]

We dwalen een heel eind af... de notatie 20200815 is heel handig voor computers (en het helpt zeker als je met amerikanen te maken hebt (hoewel, met dagnummers boven de 12 zit je wel goed )), maar niet voor dagelijks gebruik. Als iemand aan jou vraagt wat de datum is, vermoed ik dat je 'vijftien augustus' zegt, en niet 'twintig miljoen tweehonderdduizend achthondervijftien'

Ik parse ook Duits en Engels, dus het kan wel

[Daoka]

Uiteindelijk is een datum in het bestandsnaam gewoon een bestandsnaam en kan windows er natuurlijk mee omgaan. Maar is het een logische volgorde is de vraag. Hoe vaak wil je alle 1 januari bestanden van verschillende jaren bij elkaar hebben? Of de 1e van elke maand? Er zullen best uitzondering zijn maar de meeste situaties verwacht ik niet. En doe je 1 januari, 1 februari, ect dan is de sortering helemaal van de kaart.

Dat je als gebruiker niet moet aanpassen aan de software ben ik niet mee eens. Ja het klopt voor speciale gemaakte software waar jij je eigen wensen kan opgeven. Maar heb je 100 mensen die dit programma gebruiken zal er toch mensen zijn die dingen anders hadden gezien maar zich dus toch moeten aanpassen.

En dit kan je ook niet verwachten van software dat voor algemeen gebruik is. Windows heeft zoveel gebruikers dat het onmogelijk is om aan iedereens wensen te voldoen. Zelfs met iets simpels als bestandsnamen. Als simpel voorbeeld de bestandsnamen 20, 21, 201 hoe ga je hier mee om. De ene zal zeggen doe 20, 21, en 201. De andere zal zeggen 20, 201, 21. Want net als bij het alfabet pak je 1 cijfer tegelijk en sorteer daar op waardoor de 0 van 201 eerder komt als de 1 van 21. Maak je het nog een stap ingewikkelder door 021. Wordt dit als 021 of gewoon als 21? In dit geval denk ik dat beide van toepassing kan zijn voor mensen. In sommige gevallen zou ik gewoon de totale cijfers willen gebruiken. Als ik bijvoorbeeld bestanden 1 tot en met 9 heb en ik krijg een 10ste erbij kan ik alles hernoemen naar 01 tot en met 09. Dan zie ik dus liever dat ze de complete getal zien zodat je niet steeds hoeft te hernoemen. Maar ik heb bestanden ook wel eens hernoemd zodat 000 ervoor komt zodat die bovenaan de lijst komt. En dan ben ik wel blij dat de 000 niet genegeerd wordt.

En als iemand me vraagt naar me geboortedatum dat zeg ik meestal 15 augustus 2020* maar vraagt iemand me geboortedatum voor registratie zeg ik meestal 15 8 2020* aangezien een hoop systemen voor de maand ook cijfers gebruiken. Want zoals je aan het begin zei 01 moeten omzetten naar januari kan dus ook omgekeerd werken. Dat je dusbde maanden moet omzet naar cijfers.

*Niet mijn echte geboortedatum

Dus uiteindelijk is er geen 1 systeem/programma dat hetzelfde werkt en zal je je toch moeten aanpassen aan het programma.

[nandervv]

Dat kan toch, met wat slim versimpelen gewoon worden :
wwwtweakers.nl/(...) artikelnaam?
Met eventueel domeinnamen startend met www roodgekleurd.

[JAVE]

Of misschien moeten ze gewoon een toggle 'idiot mode' maken, voor mensen die het allemaal niet snappen, en een 'normal mode' voor mensen die het wel snappen...

[RayNbow]

Als ze iets zouden moeten veranderen zou dat de leesrichting van URL's moeten zijn. ipv internetbankieren.rabobank.nl (voorbeeld) zou nl.rabobank.internetbankieren veel logischer zijn voor leken en zijn fake sites veel makkelijker te herkennen, maar dat is dan helaas weer niet hoe het werkt.

De omgekeerde volgorde werd door de UK gebruikt voor emailadressen. Het YouTube-kanaal Computerphile heeft er een video over gemaakt.

[K-aroq]

Zonder deze optie:

https://www. spoofersite.com/ingbank/internetbankieren

Met deze optie:

spoofersite.com

Wij zien wel dat die eerste niet deugt, maar heel veel mensen dus niet. Die denken dat zoiets daadwerkelijk van de ingbank is als ze dat zien. Je mag hopen dat als ze die tweede optie de alarmbellen afgaan. Al verbaas ik me al niet meer over hoe slecht mensen waarnemen.

[Reactie gewijzigd door K-aroq op 27 juli 2024 11:18]

[sus]

Optie 2? Daar vullen ze nog steeds klakkeloos hun gegevens in hoor, zo dom is nu eenmaal de gemiddelde gebruiker en precies de reden waardoor dit nog steeds werkt.

[Aiii]

Volgens Google's onderzoek blijkt dat dus niet het geval.

Dit heeft ook niets met domheid te maken, maar met een gebrek aan kennis over hoe url's worden opgebouwd. Je (O)Pa van 75 kan vroeger aan de universiteit zijn diploma gehaald hebben en nog niet helemaal het verschil zien tussen een goede spoof url en een echte url, dat is niks waar deze zich voor hoeven te schamen.

[sus]

Ik zie ze in m’n winkel “van 8 tot 88” voorbij komen. De gemiddelde consument heeft geen verstand van internet, email of uberhaupt de computer. Die klikken waarschuwingen weg (“ja, dat heeft ie altijd al gedaan”), virusscanners die staan te gillen om enerzijds updates en anderzijds reeds aanwezige besmettingen. Uiteraard aangevuld met alleehande registertools en driverupdates.

Die klikken rustig een linkje aan in een mailtje “van de rabobank” wat stijf staat van de spelfouten, komen op een pagina en vullen zonder blikken of blozen hun gegevens in. Of openen de openstaande factuur van KPN terwijl ze al jaren bij Ziggo of Vodafone zitten.

Dat Google iets onderzoekt geloof ik best. Daar vult niemand in dat ze dat doen en dat ze altijd goed kijken - want dan denken ze er over na en uiteraard kiezen ze dan dat ze keurig lezen en op groene slotjes letten. De praktijk wijst anders uit. Ze kijken niet en lezen niet. Internet begint bij het google zoekveld, als je ze vraagt iets in de adresbalk in te tikken dan begint het gestotter en gestamel al. “Nee meneer, die balk waar nu ‘www.google.nl’ staat. Bovenaan. Je krijgt keihard terug dat zij geen adresbalk hebben.

[Dracquiteur]

Advocaat van de duivel hier. Ben je zeker dat jouw praktische ervaring geen vorm is van zelf selectie? Wat ik bedoel is dat mensen die extreem slecht zijn m.b.t. informatica bij jou terechtkomen, waardoor je inderdaad veel onnozelaars over de vloer krijgt, maar alles behalve de gemiddelde consument.

Uit je reactie kan ik niet opmaken wat voor winkel je uitbaat. Ikzelf heb een maand als student in de MediaMarkt gewerkt en zo'n dingen besprak ik niet bij de verkooppraatjes die ik maakte. Klanten hadden ook nooit zo'n vragen. Misschien werk je bij de customer service? Of een repairshop? In elk geval, in zo'n situaties kan je moeilijk te maken hebben met de gemiddelde consument.

In ieder geval ben ik het wel eens over dat informatica veiligheid veel beter kan. Onlangs nog een schikwekkend hoog cijfer gelezen over phishing slachtoffers (als ik me niet vergis), dus het kan zeker beter.

[sus]

Sinds 5 jaar eigenaar van een computerwinkel, daarvoor 12 jaar in loondienst bij een computerwinkel. Een zeer ruime klantenkring, waar echt de gemiddelde consument wel binnenkomt. Om te kopen, om te vragen, om te laten repareren.

Juist omdat ik al zo lang in het vak zit, en in loondienst ook heel zuid Nederland wel gezien heb en dus ervaring buiten mijn klantenkring heb, durf ik wel te zeggen dat de gemiddelde consument dommer is dan wij ze hier inschatten - op gebied van computergebruik dan he, niet dat ze letterlijk dom zijn.

Ik zie zoveel mensen die fouten maken waarvan wij hier allemaal zeggen “hoe dan??”, maar geloof me, het gebeurd.

Ze weten hoe hij aan gaat. Die blauwe E is voor internet (leuk joh, nieuwe Edge icoontje). Facebook, google, briefje in Word; dat lukt allemaal wel.

Wat de meesten gewoonweg niet zien - en daar zit de clou van het hele verhaal - is dat ze niet op de site van de bank zitten. Ze kennen de adresbalk niet, daar kijken ze nooit. Dis dat daar straks “ikspoofjegegevens.da.ru” staat, nou en? Ziet er uit als de bank, dus go.

[alex_pas]

In mijn omgeving klopt dat wel aardig. Als ik tegen mijn pa zei de adresbalk, dan dacht hij dat ik het zoekveld van Google bedoelde. Daar typte hij dan ook het adres in van de site waar hij heen wilde. Dat je dan vanuit de zoekresultaten moet doorklikken, dat was toch gewoon hoe internet werkt? Twintig jaar mijn best gedaan, nooit voor elkaar gekregen om hem aan de adresbalk te krijgen. Al stond daar ikgajehelerekeningplunderen.nu dat zag hij gewoon helemaal niet. En zo zijn er veel meer, ook mensen van in de twintig of dertig. Amazing.

[twiFight]

Maar wat is je punt? Denk je dat alleen de gemiddelde consument het internet gebruikt?
Iedereen zit er op en (utopie) ook iedereen zou veilig het internet moeten kunnen gebruiken.

[Magic Power]

Die klikken waarschuwingen weg

Ik heb veel gebruikers gezien die elk (foutmeldings)scherm 'in het midden' gewoon wegklikken. Het idee is volgens mij iets in de trand van: Ik weet toch niet wat daar staat er daar ben ik niet in geïnteresseerd. Ik wil gewoon door met wat ik aan het doen was.

Ik denk nog steeds dat een groot deel van de mensen, als ze deze (fictieve) melding in het midden van hun scherm zouden zien: "Ik ga nu dit virus op uw computer installeren. Klik op OK om door te gaan". Dat ze dan gewoon op OK klikken en niet eens proberen te lezen wat er in dat venstertje staat.

[sus]

100% dat dat gebeurd. Inderdaad, precies wat je zegt. Gewoon weg blijven klikken tot de computer stopt met zeuren, en dan gaan aan de slag.

[Reactie gewijzigd door sus op 27 juli 2024 11:18]

[P_Tingen]

Voor een deel kan ik ze dat niet eens kwalijk nemen. Mijn werklaptop heeft drie weken uitgestaan en voor ik maandag begin heb ik hem maar even aangezet zodat alle programma's even kunnen gaan zeuren dat ze updates willen hebben. En ja hoor, een voor een komen ze binnen; Windows update, HP update, Intel updates, Greenshot, Java, werkapplicaties. En ik zit al die messages weg zit te dat ik - inderdaad - de instellingen wil behouden die ik al had en naar nietszeggende progress-bars zit te kijken. Nietszeggend omdat sommige programma's rustig vier keer achter elkaar een progress-bar laat vollopen zodat ik nog steeds niet weet hoe ver de installatie is.

En ondertussen denk ik bij mezelf: waarom kan dat allemaal niet gewoon stilletjes installeren zoals browsers tegenwoordig doen, dan zou me dat heel wat gezeur besparen. En als er dan ook nog waarschuwingen tussendoor komen dan kan ik me levendig voorstellen dat mensen geërgerd alles wegklikken.

[divvid]

Bizar, alweer een tijdje terug mijn schoonmoeder een iPad gegeven. Bij de uitleg over de adres balk en IP nummers kreeg ik keihard terug dat onderliggende logica al in de jaren 60! bekend was op haar werk bij de marine. Niet zo gek want ze hadden nauwe contacten met darpa.
Inmiddels is ze (85) niet meer van dat ding af te slaan

[GeroldM]

Stel je voor, dat Google dit doorvoert. En 2 jaar later nog minder toont, want iedereen is er al gewend geraakt. Een zelfvervullende profetie, verpakt als vooruitgang, met het idee om het internet gepeupel door gebrek aan informatie onder de (winstmakende) duim te krijgen en dan die situatie met alle geweld in stand blijven houden.

Maxht corrumpeert, absolute macht....
Dat is het strijdplan van de commercieel ingestelde tech-giganten. Oftewel all tech-giganten.

[Mel33]

Denk ook dat het design is
Op de mobiel(iphone) in chrome en Safari zie je
(slotje) tweakers.net en meer niet.
Als ik erop tik zie je de halve url in dit geval, van deze site. Url balk is te kort.

Ik denk dat heel veel mensen haast geen pc meer heeft/gebruikt. Misschien weet google of dat zo is.

Ps.
de url balk is ook klein, ik vind het opgeruimd eruitzien.

[Reactie gewijzigd door Mel33 op 27 juli 2024 11:18]

[Snowbank]

Met enkel het hoofddomein in de url-balk zouden gespoofte en phishingdomeinen makkelijker te spotten zijn.

Kan iemand mij uitleggen waarom dit veiliger zou zijn?

In de voorbeeld gif blijft de "en." van en.wikipedia.org ook gewoon staan.
Dan hoeft een oplichter toch alleen spoofersite-nl/ingbank/internetbankieren/w1235 te veranderen in ingbank.internetbankieren.spoofersite-nl/w1235?

Want dan staat nog steeds de naam van de bank in de URL en ziet daardoor dus nog steeds als vertrouwd uit.

[R4gnax]

Kan iemand mij uitleggen waarom dit veiliger zou zijn?

Is het niet. En precies om de reden die je met jouw voorbeeld illustreert: gespoofte namen in het subdomein steken is minstens zo effectief, zo niet effectiever, als ze in het URL pad steken.

Firefox lost dit probleem met gespoofte domeinnamen vele malen beter. Daar toont men het hoofddomein in de URL met een hoog-contrast zwarte tint en de rest van de URL in een lager contrast grijstint. Daarmee valt het veel directer op als je op een slecht domein zit.

[Reactie gewijzigd door R4gnax op 27 juli 2024 11:18]

[RobbieB]

Ah ja, nog meer maatregelen om hun AMP domeinen te verbergen.. hier is echt geen enkele praktische reden voor waarom dit een goed idee zou zijn...

[84hannes]

hier is echt geen enkele praktische reden voor

Google denkt hier wel een praktische reden voor te hebben: verhogen van veiligheid. In plaats van te ontkennen dat er een reden is, kun je misschien ingaan op waarom je dit geen (goede) reden vindt?

Google zegt zelf dat het browsen daarmee veiliger wil maken. Met enkel het hoofddomein in de url-balk zouden gespoofte en phishingdomeinen makkelijker te spotten zij. Het bedrijf verwijst daarbij naar een studie die het zelf uitvoerde. Daaruit zou blijken dat veel gebruikers domeinen vertrouwen als daar ergens de naam van de gespoofte dienst in wordt genoemd, ook als dat bijvoorbeeld als prefix of subdomein wordt gebruikt. Door alleen het hoofdgedeelte van de url nog te tonen zouden gebruikers makkelijker zien dat het om een nepdomein gaat. Met de test wil Google kijken hoe gebruikers reageren op url's.

edit:
Rewrite

[Reactie gewijzigd door 84hannes op 27 juli 2024 11:18]

[Verwijderd]

Hij noemt amp. Als je niet bekend bent met amp, dat is wanneer Google je site opeet en serveert via Google. Google knipt ook alles uit je site wat ze niet leuk vinden en als je niet meedoet aan amp, dan krijg je een slechte ranking in de zoekmachine.

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

Het zou me helemaal niks verbazen als google.com/amp straks ook weggeknipt wordt en het voor de gebruiker geheel ondoorzichtbaar is dat ze niet echt op de site zijn die ze wilden zien.

[meximal]

Het weglaten van google.com/amp is precies wat vorig jaar nieuws was: nieuws: Google begint met verbergen url's van amp-pagina's in Chrome

Heb even geen chrome browser bij de hand, dus ben benieuwd of dat nu inderdaad zo is.

[Verwijderd]

Ik gebruik zelf gelukkig geen Chrome, dus ik kan het ook niet verifieren. Ik wil die spyware eigenlijk ook niet installeren om te zien of ze dit doen

[84hannes]

Hij noemt amp. Als je niet bekend bent met amp (...)

Hij noemt AMP en ik ben ook geen fan van AMP, maar ik zie niet wat dat er mee te maken heeft.

Het zou me helemaal niks verbazen als google.com/amp straks ook weggeknipt wordt en het voor de gebruiker geheel ondoorzichtbaar is dat ze niet echt op de site zijn die ze wilden zien.

Dat gebeurt volgens mij al in Google Chrome, maar dat staat helemaal los van dit artikel en ook los van mijn vraag. Er zijn zeker redenen te bedenken waarom Google dit niet zou moeten doen, maar ik vraag wat hij vindt van Google's reden om het wel te doen. Simpelweg ontkennen dat die reden bestaat is in mijn ogen wat zwakjes.

[Reactie gewijzigd door 84hannes op 27 juli 2024 11:18]

[Verwijderd]

Dan heb ik niks gezegd ;-) @84hannes

[Reactie gewijzigd door Verwijderd op 27 juli 2024 11:18]

[84hannes]

Fixed, thanks!

[Bergen]

Prefixes zoals https en www worden daarbij niet langer getoond.

Die niet nee, maar alle andere prefixes wel:

https:// gathering.tweakers.net /forum/list_topics/121 wordt getoond als gathering.tweakers.net

(even wat spaties ertussen, anders verandert de link in de naam van het forum)

Als je met je muis over de url-balk beweegt verschijnt in donkergrijs de rest van de url ook; je hoeft niet beslist op de url-balk te klikken.

[Reactie gewijzigd door Bergen op 27 juli 2024 11:18]

[TijsZonderH]

Prefixes zijn geen subdomeinen, voor zover ik het zie blijven die wel staan.

[comecme]

Dat wat je prefix noemt heet toch het scheme / schema?

[Bergen]

Niet helemaal. Een schema bepaalt het formaat van de hele url. http en https zijn namen van schema's. Dan volgt de dubbele punt en dan de rest van de url, waarvan het formaat afhangt van het schema. http en https volgen dus een soortgelijk schema. Maar er zijn nog veel meer schema's, bijvoorbeeld eentje voor telefoonnummers: tel:[phone]. Daar komen niet eens slashes in voor.

De naam van het schema + de dubbele punt = de prefix.

Prefixes zijn geen subdomeinen, voor zover ik het zie blijven die wel staan.

Technisch gezien is www ook een subdomein; een webserver maakt geen onderscheid tussen www en andere subdomeinen. Maar Chrome maakt daar zo te zien een uitzondering voor.

[Reactie gewijzigd door Bergen op 27 juli 2024 11:18]

[comecme]

Dan is het toch het schema dat verborgen gaat worden? En niet een "prefix"? Dus waarom "niet helemaal"?

Hooguit wordt misschien ook het subdomein "www" verborgen, dat is me niet duidelijk.

[Bergen]

Ja, en we zitten op de grens van mierenneuken maar inderdaad, wat er wordt verborgen is: de prefix (oftewel schema + dubbele punt) en de twee slashes erna: http:// of https://, en eventueel www.

Uit de originele URL specificatie van Tim Berners-Lee (opperhoofd van het internet):

Within the URL of a object, the first element is the name of the scheme, separated from the rest of the object by a colon. The rest of the URL follows the colon in a format depending on the scheme.

[Reactie gewijzigd door Bergen op 27 juli 2024 11:18]

[kodak]

Prefixes van een fully qualified domain name kunnen onderdeel zijn van een subdomein. Ik vermoed dat ze dus alleen subdomeinen verbergen die aan bepaalde voorwaarden voldoen.

[Opperpanter2]

In de animatie verdwijnt ook de querystring?

[spone]

Ik zie in het gifje geen querystring, enkel een pad (/wiki/...) en een anchor (#iets). Een querystring begint met een vraagteken.

[Opperpanter2]

Ja pad bedoel ik. Meer dus dan alleen prefixes die verborgen worden. Mijn punt was meer dat de titel van het artikel hier onvolledig is.

[Reactie gewijzigd door Opperpanter2 op 27 juli 2024 11:18]

[Redstone]

Dan moet je Wikipedia even aanpassen https://en.m.wikipedia.org/wiki/Subdomain

[bartje]

Als ik het goed begrijp verdwijnt nu dus ook gathering. Lijkt me niet echt handig als je hoofd en subdomein niet uit elkaar kunt houden.

[Bergen]

gathering blijft gewoon staan. Ik zit het nu net te testen.

[Reactie gewijzigd door Bergen op 27 juli 2024 11:18]

[Raymond Deen]

Ergens snap ik die redenatie wel, maar maak het dan in vredesnaam ook gewoon mogelijk om de hele URL gewoon te tonen wanneer dat je voorkeur is!
Ik werk veel met subdomeinen om naar verschillende servers te gaan en heb echt geen zin om elke keer weer opnieuw over de browser balk te hangen met de muis om te kijken of ik wel op de goede server bezig ben...

[Djordjo]

Daarnaast komt er een optie in het Chrome-menu om standaard alsnog de hele domeinnaam te tonen als gebruikers dat willen.

[TijsZonderH]

Aluhoedje op maar de vraag is natuurlijk hoe lang ze dat blijven doen. Nu is het superduidelijk in het contextmenu, straks wordt het misschien veel verder weggestopt waar je het amper vindt, daarna alleen nog via een flag toe te voegen... Zou niet de eerste keer zijn dat zoiets gebeurt.

[Raymond Deen]

Dat bedoel ik. Zelfs de flag daarvoor is weg geweest en (paar) versie(s).

[Opperpanter2]

Subdomain wordt gewoon getoond

[walkstyle]

Geld dit dan ook voor aws.amazon.com? wel onhandig voor bedrijven die hun bedrijfsnaam in de sub-domein hebben zitten.

[Bergen]

Geld dit dan ook voor aws.amazon.com? wel onhandig voor bedrijven die hun bedrijfsnaam in de sub-domein hebben zitten.

Je ziet het subdomein wel gewoon, dus er blijft "aws.amazon.com" over en de rest van de URL valt weg. Zit het nu te proberen, ik zit op een of andere subsite van amazon en zie in de balk "portal.aws.amazon.com" staan. Maar als ik op de balk klik verschijnt de complete (lange) url.

[GoBieN-Be]

Maar www gaat wel weg vallen.
Er zijn genoeg kleine bedrijven die hun domeinnaam ook gebruiken in Active Directory. Daar zal de website intern niet werken als ze geen www voorzetten.

[Bergen]

Het is alleen maar uiterlijk, achter de schermen blijft www er gewoon voor staan. Zodra je op de url klikt, om hem bijvoorbeeld te editten, verschijnt www weer.

[GoBieN-Be]

Maar als de gebruikers kijken naar de balk zien ze geen www meer. Grote kans dat na verloop van tijd ze ook die www niet meer zullen typen.

Ik vind dit geen goede aanpassing, en verdenk Google ervan om mensen nog meer naar de zoekmachine te pushen.

[Bergen]

Bij de meeste websites hoef je al 10 jaar geen www meer ervoor te typen. Ik zou uit mijn hoofd niet één kunnen opnoemen waar dat nog wel moet.

[GoBieN-Be]

Er zijn wel degelijk use-cases voor, zie mijn eerder bericht.

[slaay]

An experiment in Chrome 86 shows the domain name by default and full URL on hover

Bron: https://blog.chromium.org...-spot-spoofs-url.html?m=1

Dat is iets wat anders dan wat de titel van dit artikel ons doet geloven. Subdomeinen worden dus nog wel gewoon getoond, alleen de rest van de url wordt verborgen.

[Reactie gewijzigd door slaay op 27 juli 2024 11:18]

[TijsZonderH]

Het woord subdomein stond inderdaad verkeerd in de titel, dat moet prefix zijn.

[SMGGM]

Ik begrijp de stap best wel en denk oprecht dat dit zal bijdragen aan de veiligheid.
Bij veel spoofing probeert men de gebruiker te misleiden door ellenlange domein domein en subdomeinen met in het subdomein de verwijzen van de webwinkel, bank, koerier,... en goochelen vaak met termen als secure.banking.naam_bank.een_of_ander_id.com

Omdat er dan al zoveel websites zijn die gelijkaardige dingen bevatten is het voor de modale gebruiker niet meer te begrijpen wat nu belangrijk is en wat niet. De Tweakers zullen het ongetwijfeld wel weten, maar het feit dat in een basis internet cursus een heel hoofdstuk wordt besteed om het domein uit de volledige URL te halen stelt mij de vraag: waarom heeft niemand dit eerder gedaan.
Op deze manier is het transparant, zie je daar niet de naam van je bank staan, GA DAN NIET VERDER.
Ontcijferen van je URL of vragen aan iemand dat al wat slechter kan zien wat grijs is en wat nu zwart, is dan verleden tijd.

[bilbob]

de modale gebruiken is imho niet relevant. Want die begrijpen en toch al niets van..

[GoBieN-Be]

Ik een paar geleden een suggestie naar Mozilla gestuurd om het hoofddomein in een ander fontgrootte of vetjes te plaatsen, eventueel met een soort highlighting om het onderscheid te tonen tussen hoofddomein en subdomein en resource locators, query string etc.