image

Google verwijdert optie voor weergeven https en www in Chrome

vrijdag 13 december 2019, 14:33 door Redactie, 13 reacties

Met de lancering van Chrome 79 heeft Google de optie verwijderd om https en het www-subdomein standaard in de adresbalk van de browser weer te geven. Vorig jaar kwam Google onder vuur te liggen omdat het in Chrome 69 "triviale subdomeinen" zoals www niet meer in de adresbalk weergaf. Niet alleen zorgde de maatregel in bepaalde gevallen voor problemen, tegenstanders noemden het een beveiligingsrisico.

Zo stelden tegenstanders dat het voor een aanvaller veel eenvoudiger zou worden om zich als het hoofddomein voor te doen. Er was echter een optie "chrome://flags/#omnibox-ui-hide-steady-state-url-scheme-and-subdomains" waarmee het www-subdomein weer in de adresbalk werd getoond. Daarnaast besloot Google de maatregel vanwege alle kritiek zelf terug te draaien. Het bleek echter om een tijdelijke maatregel te gaan.

Met de lancering van Chrome 76 koos Google ervoor om zowel https als www niet meer in de adresbalk te tonen. Gebruikers hadden echter nog steeds de optie voor het weergeven van https en www. Met de lancering van Chrome 79 deze week is daar een eind aan gekomen. De optie is niet meer beschikbaar, wat inhoudt dat gebruikers die https en www willen zien nu twee keer in de adresbalk moeten klikken of Googles Chrome-extensie "Suspicious Site Reporter" moeten installeren.

Reacties (13)
13-12-2019, 15:08 door Anoniem
Ik zou maar helemaal niks meer tonen in die adresbalk, dan wordt het pas echt veilig.
13-12-2019, 15:18 door Anoniem
Pfffff. Tijd om over te gaan op Microsoft Edge (Chromium). Better, sneller en zonder Google, wat zelfs ik als fanboy inmiddels ook niet meer zo top vindt.
13-12-2019, 15:45 door Anoniem
Het wordt ondertussen steeds slimmer en gemakkelijker en veiliger om geen gebruik te maken van chrome
13-12-2019, 16:53 door Reinder
Iemand enig idee wat de reden hierachter is? Die informatie is beschikbaar in de browser, het lijkt me toch een kleine moeite zo'n weergave-optie configureerbaar te maken met een eenvoudige schakelaar of desnoods een vlaggetje wat dieper in de configuratie. Ik zie niet in hoe het verwijderen van zo'n optie dingen beter, sneller, of veiliger kan maken. Ik kan niet snel een andere reden vinden "google decided most users won't need this information", maar ik kan me moeilijk voorstellen dat dat alleen afdoende reden is om de mogelijkheid in z'n geheel te verwijderen.
13-12-2019, 17:40 door Anoniem
Door Reinder: Iemand enig idee wat de reden hierachter is? Die informatie is beschikbaar in de browser, het lijkt me toch een kleine moeite zo'n weergave-optie configureerbaar te maken met een eenvoudige schakelaar of desnoods een vlaggetje wat dieper in de configuratie. Ik zie niet in hoe het verwijderen van zo'n optie dingen beter, sneller, of veiliger kan maken. Ik kan niet snel een andere reden vinden "google decided most users won't need this information", maar ik kan me moeilijk voorstellen dat dat alleen afdoende reden is om de mogelijkheid in z'n geheel te verwijderen.
Het schijnt mij toe dat er een soortement van newspeak-gedachte achter zit. Ze proberen "het verhaal van het web" om te buigen naar iets wat meer lijkt op wat ze hebben willen. Minder technische details, meer "user experience", oftewel "mond houden en doorconsumeren".

En, nouja, google verdient z'n poen met advertenties, met informatie vergaren en doorverkopen. Dus als ze "het verhaaltje" kunnen vormen naar hun eigen idee levert ze dat uiteindelijk meer geld op. Al met al geen goede ontwikkeling voor ons.
13-12-2019, 17:52 door Anoniem
Door Anoniem: Ik zou maar helemaal niks meer tonen in die adresbalk, dan wordt het pas echt veilig.
Inderdaad ze kunnen de adresbalk beter maar helemaal weglaten, niemand doet daar toch iets mee.
(naar mijn ervaring tikken mensen als je ze een URL geeft deze gewoon in de Google zoekbalk in)
14-12-2019, 03:00 door Jean Vohur
Door Anoniem: Pfffff. Tijd om over te gaan op Microsoft Edge (Chromium). Better, sneller en zonder Google, wat zelfs ik als fanboy inmiddels ook niet meer zo top vindt.

Beter om over te gaan op Chromium! Niet op de zoveelste afgeleide daarvan. Nu weer Edge dat deze engine gebruikt maar niets relevants toevoegt (behalve dan de onvermijdelijke telemetrie).
14-12-2019, 03:28 door allestein
Goed idee van Google! Laten we in de straatnaambordjes ook eens "straat" , "weg", "laan" enz. weglaten; dat is toch allemaal ook overbodig?!
14-12-2019, 10:20 door Jean Vohur - Bijgewerkt: 14-12-2019, 10:20
Door allestein: Goed idee van Google! Laten we in de straatnaambordjes ook eens "straat" , "weg", "laan" enz. weglaten; dat is toch allemaal ook overbodig?!

Dat kan je niet vergelijken met het weglaten van www. in een URL. Want een URL is hiërarchisch opgebouwd, waardoor het weglaten van www. niet tot verwarring met andere domeinnamen zal leiden.
14-12-2019, 10:42 door Briolet
Door Reinder: …het lijkt me toch een kleine moeite zo'n weergave-optie configureerbaar te maken met een eenvoudige schakelaar of desnoods een vlaggetje wat dieper in de configuratie.

De weergave was configureerbaar,, dus kostte het nu juist moeite het er uit te halen. (-:

Maar in zijn algemeenheid zijn dit soort uitzonderingen die je via vlaggetjes en schakelaartjes activeert een bron voor toekomstige bugs. Nu zal het goed geïmplementeerd zijn, maar elke keer als je iets in dat deel van de code aanpast moet je weer nalopen of al dit ook compatibel is met al je ingestelde vlaggetjes en schakelaars. En je moet dit goed documenteren en hopen dat een volgende programmeur ook eerst alles doorleest voordat hij aan de aanpassingen begint.

Strakke code met minder uitzonderingen is op den duur wel veiliger.
14-12-2019, 12:00 door Anoniem
Daarom ga ik nog wel eens een keertje naar de developer console via Ctrl+Shift+I.
Dat zouden wat meer mensen met wat basis kennis eens moeten doen.
Werkt heel verhelderend op je inzichten, als je weet hoe alles werkt.

Krijg je tevens ook een aardig beeld, wat de massa mist aan onveiligheidsbesef op de Interwebz infrastructuur.
Het is echt nog erger dan de spreekwoordelijke Zwitserse Gatenkaas, waar men het altijd over heeft.

JavaScript errors notifier overzicht analyseren, kwetsbare code via Retire.JS doorspitten.
CSP en header setting gegevens (Recx security analyser). Valideren naar client en webserver site.
Vulnerabilities kijken na en zonder excessieve info proliferatie.

Een iets handige script kiddie kan de was doen via een juist shellscriptje op een ongepatched systeem.
Het handhaven ertegen en het opruimen van de bloat, crap, fraud en cybercrime, is dweilen met alle kranen full open.

Google gaat ons steeds vaker en verder door hoepeltjes laten springen. Dit vanwege "security through obscurity".
Het monopoliseren van hun core-business moet ongezien aan de andere kant van het scherm van menigeen verlopen.
Slechts dan kunnen ze volgens hen voldoende het potje leeghalen, alhoewel het een rupsje-nooit-genoeg blijft.

Daarom zal het op den duur heel naar voor de eindgebruikers aflopen, wat ik u allen brom.
We zitten al opgesloten binnen een tracking cocon met weinig kans op een vrije info-vlinder bestaan.

luntrus
16-12-2019, 09:43 door Anoniem
Begint langzaamerhand een troep browser te worden zo te zien.
25-12-2019, 15:03 door Anoniem
Beste bladeraar-beveiligers en beste browser-aan-de-tand-voelers,

In vele andere opzichten is Google Chrome of chromium onveiliger dan firefox
of op firefox gebaseerde browsers, zoals bijvoorbeeld Cliqz Internet.

Bijvoorbeeld in het geval van preloading: (denk aan sub-resource link veiligheid):
Wat merkt jScheid hierover op bij een bug-evaluatie:

### Preloading

`<link rel="preload">` doesn't work as expected in current Chrome versions, even
if the integrity attribute is added to the `link tag (which the current version
of webpack-subresource-integrity does _not_ do.) The resource will be loaded
twice, defeating the purpose of preloading. This issue doesn't appear to exist
in Firefox or Safari. See issue #111 for more information.
This plugin adds the integrity attribute to `<link rel="preload">`
tags, but preloading with SRI doesn't work as expected in current
Chrome versions. The resource will be loaded twice, defeating the
purpose of preloading. This problem doesn't appear to exist in
Firefox or Safari. See [issue
#111](https://github.com/waysact/webpack-subresource-integrity/issues/111)
for more information.
En ook hier nog vele implementatie zwakheden, lees:
https://thehackernews.com/2019/08/http2-dos-vulnerability.html

Wat voor pre-loading geldt, geldt ook voor CSP beveiliging en nog vele andere zaken meer.
Dit alles wel afhankelijk van de combinatie van zwakheden en/of gebruikte technieken,
net als altijd bij input dat kan worden gecontroleerd en de manipulatieve methoden,
zoals o.a. bij XSS-DOM sources and sinks.
Het een wil niet werken of succesvol resultaten geven zonder de aanwezigheid van de andere voorwaarde(n).

Goed om eens in te duiken zo rond deze tijd van het jaar. "Time at your hands?".
Baat het niet, het schaadt zeker ook niet zulke website evaluatie verkenningen.
Het brengt veel inzicht en tevens het beself hoe men zich bij heel veel websites op drijfzand kan wanen.

Toch een fijn jaaruiteinde gewenst, van de security-optimist tot in de kist,

Veel plezier,

luntrus
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.