Gecompromitteerde wachtwoorden kunnen in Chrome makkelijker gewijzigd worden. Ontwikkelaars kunnen een forwarding toevoegen voor de betrokken gebruikers.
Wachtwoorden die tijdens een data-inbreuk zijn afgetapt, kunnen in de toekomst makkelijker worden gewijzigd op de websites van Chrome. Om dat te doen, zullen de ontwikkelaars een omleiding inbouwen die aan de gebruikers zal verschijnen zodra het lek bekend is. Apples Safari en iCloud Keychain gebruiken dat al sinds 2018 en nu volgt Google dit voorbeeld.
Deze functie voor Chrome zal in versie 86 verschijnen, dus ergens in de komende weken. Gebruikers worden al gewaarschuwd door de wachtwoordcontrole als hun in de browser opgeslagen wachtwoord voor een website in een bekend datalek verschijnt. Google zal je dan voorstellen om je wachtwoord onmiddellijk te wijzigen. Om ervoor te zorgen dat de betrokkene niet eeuwig hoeft te zoeken waar en hoe hij die verandering kan doorvoeren, zal een forwarding worden ingebouwd om meer zekerheid te bieden.
Natuurlijk kan Google de betreffende pagina zelf niet vinden. Daarom moeten de ontwikkelaars daarvoor zorgen. Zij kunnen de url gebruiken in het formaat “/.well-Known/change-password” voor dat doel, schrijft Bleeping Computer. Als er geen geschikte url is, leidt Chrome je via een knop naar de overzichtspagina.
In de bètaversie van Chrome 86 kun je deze functie al testen door in de adresbalk het volgende te typen:
chrome://flags/#well-known-change-password
en die te activeren.
Uitgestelde veranderingen
De huidige stabiele versie van Chrome is 85. Naast 20 gefixte security-lekken heeft Google gewerkt aan de prestaties en het tabbladbeheer geoptimaliseerd. Tabbladen kunnen sindsdien in- en uitgevouwen worden, op tablets zijn er kleine voorvertoningen van de inhoud om een beter overzicht te houden. Bij versie 86 zou Chrome om veiligheidsredenen eigenlijk moeten voorkomen dat niet-versleutelde inhoud afkomstig is van HTTPS-pagina’s . Door de coronacrisis is die ontwikkeling echter teruggeschroefd.
Ook is een wijziging in de behandeling van cookies later ingevoerd dan oorspronkelijk gepland. Degenen die geen SameSite-attribuut hebben, worden automatisch beschouwd als SameSite=Lax. SameSite=None,oftewel als ze van derden komen, moeten als veilig worden gemarkeerd en over HTTPS lopen om Google in staat te stellen die te versturen.