Chrome 66 verschijnt met autoplayrestricties en exportoptie voor wachtwoorden

Google heeft Chrome voor Windows, Mac, Linux, Android en iOS een update gegeven naar versie 66. De belangrijkste verbeteringen zijn dat autoplay met geluid nu standaard geblokkeerd wordt en dat de gebruiker alle wachtwoorden in één keer kan exporteren.

De autoplayrestricties zouden eigenlijk al in januari bij de komst van Chrome 64 in de browser verschijnen, maar na uitstel is dat bij de huidige introductie van Chrome 66 het geval. Er is geen sprake van een volledige blokkade van de autoplayfunctie bij sites; video's die geluid niet aan hebben staan, spelen nog wel automatisch af. Als een gebruiker 'interesse heeft getoond' speelt de video eveneens af, ook met geluid. Dat is bijvoorbeeld het geval als gebruikers de site op mobiel hebben toegevoegd aan het startscherm, ergens hebben geklikt, of met de desktopversie vaker media op de site hebben bekeken.

Bij de instellingen voor het beheren van wachtwoorden is er nu de optie om alle door Chrome opgeslagen wachtwoorden voor sites en diensten te exporteren. Dit gebeurt in een onversleuteld csv-bestand en Chrome geeft dan ook een waarschuwing weer. Bij Windows moet de gebruiker zijn inlognaam en wachtwoord invoeren om het bestand te kunnen exporteren. Die export kan dan bijvoorbeeld weer in een wachtwoordmanager geïmporteerd worden.

Chrome 66 wachtwoordenChrome 66 wachtwoordenChrome 66 wachtwoorden

Google houdt bij een kleine groep gebruikers een test met Site Isolation bij Chrome 66. De beveiligingsfunctie zorgt ervoor dat sites altijd in verschillende processen draaien en geen data van andere sites kunnen benaderen. Sites draaien al afgeschermd van elkaar, maar Site Isolation zorgt voor een extra beschermlaag die ongeoorloofde toegang ook voorkomt bij misbruik van processorbugs zoals Spectre.

Verder ondersteunt de browser vanaf versie 66 Symantecs public key infrastructure niet meer wat certificaten die voor juni 2016 zijn uitgegeven betreft. Dit betekent dat Chrome een waarschuwing geeft bij het openen van ssl/tls-verbindingen op basis van oude certificaten van Symantec of een van de merken van het bedrijf, zoals Thawte, VeriSign, Equifax, GeoTrust of RapidSSL.

Door Olaf van Miltenburg

Nieuwscoördinator

18-04-2018 • 10:31

49

Reacties (49)

49
49
26
4
1
18
Wijzig sortering
Voor de websitebouwers onder ons:
Als je een video van YouTube gebruikt als achtergrond, bijvoorbeeld voor in de header van een pagina, voeg dan even 'mute=1' toe aan de embed URL. Dan blijft het werken met de nieuwste versie van Chrome.
Wat ik nooit heb begrepen is de wijsheid van de achterlijke 'versioning'. In 2009 begon Firefox en Chrome dit te doen, we zijn nu 9 jaar verder en zitten op versie 66 dus ongeveer 7.3 versies in 1 jaar tijd.

Kan je jezelf voorstellen dat je over 25 jaar zegt tegen iemand, je moet even je browser updaten naar versie 248. Wat is hier gebeurd? Na het sleutelen aan de kernel van Linux (zo'n kleine 27 jaar) komt versie 5 bijna uit.

Het mooie hiervan is dat ik dit niet eens hoefde op te zoeken want ik ben ondertussen gewend dat ik op versie 4 draai. Laten we eerlijk zijn, wisten jullie op welke Chrome versie bij jullie geinstalleerd was voordat dit bericht naar voren kwam?

Een major versie is vrij handig om te hebben omdat je simpelweg een acurate gok kan maken of iets wel of niet ondersteund word. Zo weet je dat als je te maken hebt met Internet Explorer 8, je misschien beter een andere css bestand aan moet leveren omdat je weet dat die browser niet door de acid test komt.

En wat is nu op "plugin" niveau anders in versie 65 vergeleken met 66. Moet ik mijn plugins weer updaten of blijven deze nogsteeds werken? Waar is de logica?

[Reactie gewijzigd door Xorifelse op 23 juli 2024 08:23]

Anoniem: 457607 @Xorifelse18 april 2018 13:04
"Kan je jezelf voorstellen dat je over 25 jaar zegt tegen iemand, je moet even je browser updaten naar versie 248"

Nee, want browsers updaten zichzelf nu al, laat staan over 25 jaar. Het nummer doet er op geen enkele wijze toe. Chrome released gewoon iedere 6 weken, en dan gaat het nummertje +1. Dit is zo voorspelbaar dat je zelfs de leeftijd van een release kunt berekenen.

Niks mis mee.
Nee, want browsers updaten zichzelf nu al, laat staan over 25 jaar. Het nummer doet er op geen enkele wijze toe.
Buiten het feit dat deze automatische updates ook uitgezet kunnen worden, update mijn computer helemaal niets totdat ik het commando geef, geen enkele Linux distributie doet dit automatisch omdat in elke implementatie het een wachtwoord nodig heeft.
Chrome released gewoon iedere 6 weken, en dan gaat het nummertje +1. Dit is zo voorspelbaar dat je zelfs de leeftijd van een release kunt berekenen. .
Toch vreemd dat ik op 7.3 versies in 1 jaar uitkom, en jij 8.5. Dus in een paar jaar tijd is er al een afwijking op jouw voorspelbare rekensom.
Niks mis mee.
Voor de hedendaagse gebruiker niet nee, die zal het allemaal een worst interesseren. Vooral met het argument dat je gebruikt dat voor de meeste mensen het gewoon automatisch update waarom moeten hun dan zo erg afwijken van een normale versie patroon?

Ik heb het over ontwikkelaars, die met 1 blik op de major versie kunnen zien welke API hun kunnen gebruiken om te communiceren met de applicatie. Een major versie geeft vaak aan dat er geen rekening is gehouden met backwards compatibility om een schone code over te houden. Nu moet ik onderzoek gaan doen of iets wel of niet meer werkt als ik bijvoorbeeld een extensie heb geschreven voor Chrome.

[Reactie gewijzigd door Xorifelse op 23 juli 2024 08:23]

Anoniem: 457607 @Xorifelse18 april 2018 16:21
Je hebt nog steeds geen steekhoudend argument waarom 5.7.3.1 beter is dan Chrome 66. Buiten dat geen normaal mens daar iets van meekrijgt, is er ook in ander opzicht geen verschil.

"Ik heb het over ontwikkelaars, die met 1 blik op de major versie kunnen zien welke API hun kunnen gebruiken om te communiceren met de applicatie"

Dat is niet hoe het web werkt. In principe is alles wat aangeboden wordt, onbeperkt backwards compatible, een paar heel kleine uitzonderingen daargelaten. Dus het maakt geen donder uit. Als ik een geolocation API kan gebruiken in versie 44, kan ik dat ook alle versies daarna.
Is natuurlijk niet helemaal waar wat je nu zegt dat het niet op gaat voor (web)-ontwikkelaars. Anders zouden er geen sites zijn zoals https://caniuse.com

Browsers zijn in de praktijk toch echt een wirwar aan verschillende functionaliteiten per browser, per versie en ze zijn ook echt niet vies om dingen te deprecaten https://developer.mozilla...tures#Deprecated_features
Anoniem: 457607 @TrisBe18 april 2018 23:11
Een klassieke versie nummering geeft ook niets aan over deprecation van een individuele feature, dat kan ook niet gezien de duizenden features die allemaal onafhankelijk voortbewegen.

Punt blijft: een ontwikkelaar kan aan 5.7.2 absoluut niet zien wat er wel/niet inzit, net zomin als bij v66.
Dan moet je je toch eens inlezen op https://semver.org

Kort samengevat, als je een versie 1.0.0 hebt, heb je de volgende opties:

* Je fixt een bug, en de api blijft backwards compatible > 1.0.1
* Je voegt functionaliteit toe, maar de api blijft backwards compatible > 1.1.0
* Je hebt iets gedaan waardoor de api veranderd, derde partijen moeten (mogelijk) werk verrichten om hun product weer compatible te makrn > 2.0.0

Waarbij compatible zijn kan betekenen dat er iets niet meer werkt. Bijvoorbeeld event handling is gewijzigd. Maar ook is het mogelijk dat het om iets visueel gaat op _mijn_ website. (pixel preciesie van de vormgever)

De event handlers is voor mij nog steeds hét voorbeeld hoe chrome (met versie 56) in staat was om het halve web "kapot" te maken.

"zo werkt het web niet, alles is backwards compatible" gaat echt niet op.

De eerste goede link die ik zo snel even kon vinden:
http://tonsky.me/blog/chrome-intervention/
Anoniem: 457607 @GateKeaper19 april 2018 12:30
Je draait er nog steeds omheen. Ik ben bekend met versie schemas, zit al 25 jaar in software ontwikkeling.

Punt blijft overeind dat aan een browser versie nummer je niet kunt zien welke feature ondersteund danwel deprecated is, of deze nu 5.3.1 of 66 heet. Het is er op geen enkele wijze uit af te leiden.
Klopt, je kan niet zien wat er kapot gaat. Wel kan je er vanuit gaan dat er tussen 5.3.1 en 5.3.2 maar ook 5.900.3 niks kapot gaat.
Dat is niet hoe het web werkt. In principe is alles wat aangeboden wordt, onbeperkt backwards compatible, een paar heel kleine uitzonderingen daargelaten.
Ik zou willen dat Google ook zo dacht, voordat ze de event listeners allemaal passive bij default maakten:

http://tonsky.me/blog/chrome-intervention/
Waarschijnlijk gewoon een kwestie van marketing. Van 65 naar 66 klinkt als een grotere stap dan van bijv. 5.6 naar 5.7. Gevolg: mensen updaten sneller en er wordt meer aandacht aan besteed in de media.

Ik ben het wel met je eens, functioneel is deze 'versioning' totaal niet. Bij een grote of belangrijke update zou dit gewoon meteen duidelijk moeten zijn. Nu is zo'n update gewoon weer de zoveelste in het lijstje.
Bij sommige software maakt het ook veel minder uit. Het is maar net waar je waarde aan hecht. De Linux-kernel is juist de andere extreme. Gelukkig heeft Linus na eeuwig in 2.26.X te blijven gemaakt de sprongen ook wat groter gemaakt. Valt me vaak op dat van die open source-software vaak op 0.0.0.1 alpha 0.3 blijft hangen terwijl het vaak prima werkt. Dan heb ik liever wat normalere versioning dan doen alsof je een brak product hebt.
Kan je jezelf voorstellen dat je over 25 jaar zegt tegen iemand, je moet even je browser updaten naar versie 248. Wat is hier gebeurd? Na het sleutelen aan de kernel van Linux (zo'n kleine 27 jaar) komt versie 5 bijna uit.
[..]
Een major versie is vrij handig om te hebben omdat je simpelweg een acurate gok kan maken of iets wel of niet ondersteund word. [..]
En wat is nu op "plugin" niveau anders in versie 65 vergeleken met 66. [..]
Die laatste opmerking is wel erg vreemd als je eerder in je post de vergelijking met de Linux-kernel maakt. Als jij mij kunt vertellen welke logica Linus aanhoudt om naar een volgende major versie van Linux te gaan dan ben ik erg benieuwd...? Bij mijn beste weten is dat ongeveer van het niveau "ach, het wordt wel eens een keertje tijd"; met API-ondersteuning heeft het in elk geval helemaal niets te maken.
Als jij mij kunt vertellen welke logica Linus aanhoudt om naar een volgende major versie van Linux te gaan dan ben ik erg benieuwd...?
Hij heeft aangegeven dat nu te doen om de 2 miljoen veranderingen op git.

Met de redenering dat nummers tot de 20 makkelijker te onthouden zijn, dus 4.17.#### zou waarschijnlijk de laatste versie zijn met 4. Met de API ondersteuning heeft het in dit geval niet te maken, heeft ook weinig nut in dit geval omdat je niet met API's werkt maar meer met de bibliotheken die je gebruikt voor je applicatie.
Het was eigenlijk een rhetorische vraag; op versienummers (en user agents) vertrouwen is een laatste redmiddel, dat zou je eigenlijk sowieso niet moeten doen. Als je vertrouwt op user agent sniffing ("ik zie dat je ff bent, dus dan slaan we dit deel van de site over") dan moet je continu alle browsers in de gaten houden om te kijken of ze de functionaliteit die jij gebruikt toevoegen, zodat je dat stuk van je site ook voor die gebruikers beschikbaar kunt maken. Het is veel beter om te werken met feature detection (aan de browser vragen "ondersteun je feature xyz?"). Ik kan me (anno 2018, laat staan over 25 jaar) geen realistische situatie voorstellen waarin het voor de gebruiker uit zou mogen maken of ie Chrome 247 of Chrome 248 draait.

Dat gezegd hebbende:
omdat je niet met API's werkt maar meer met de bibliotheken die je gebruikt voor je applicatie.
Ik geef toe, we noemen het geen APIs maar system calls. Verder is het verhaal echter hetzelfde. Je kunt zelfs opzoeken in welke kernel versie elke syscall is toegevoegd (en nee, dat zijn geen makkelijk te onthouden nummers; een heleboel zijn "2.x.y").
Hij heeft aangegeven dat nu te doen om de 2 miljoen veranderingen op git.
Ik had juist begrepen dat dat zo'n "mooie reden" was, dat ie daarom juist had besloten om het niet te doen; dat zou te voorspelbaar zijn!? Hoe dan ook; kunnen we het erover eens zijn dat het een nog veel slechtere reden is dan wat Chrome doet?
Eindelijk autoplay ristricties, niks vervelender dan je kapotschrikken/rotzoeken als er ineens ergens geluid vandaan komt
Vooral op bepaalde sites :o
Zeker weten dat het helpt?

Als een gebruiker 'interesse heeft getoond' speelt de video eveneens af, ook met geluid. Dat is bijvoorbeeld het geval als als gebruikers de site op mobiel hebben toegevoegd aan het startscherm, ergens hebben geklikt, of met de desktopversie vaker media op de site hebben bekeken.
Haha, scherp. Precies wat ik al dacht bij het lezen van de reactie van mikeventura :+
Welke sites? Ik begrijp echt niet waar het over gaat. :X
Thank you Captain Obvious.
Ik weet ook niet waar ze het over hebben, niks raars aan tech-nieuws sites toch? ben mij van geen kwaad bewust :P
Niet alleen de Captain Obvious-sites, maar bezoek eens een gemiddelde Amerikaanse newssite (CNN, Fox, ABC News, CBS etc). Bijna overal beginnen video's automatisch af te spelen met geluid. Bloedirritant, en die ellende zie je op steeds meer sites. Mag hopen dat het met deze update een keer stopt met die onzin.
Moet je maar niet verveeld 'bepaalde' sites bezoeken tijdens saaie meetings op je werk... :+
CCN.com bijvoorbeeld, dat kan echt niet tijdens je pauze!
Dit dus. Serieus irritant en niet iets wat ik van CNN zou verwachten.
Ik heb de originele facebook client o.a. hierom laten varen. Ik weet dat je het uit kan zetten maar ik vind het een achterlijke default setting om video's automatisch af te spelen zeker als je dat ook via mobiele data doet. Kan echt niet.

[Reactie gewijzigd door Koffiebarbaar op 23 juli 2024 08:23]

Autoplay standaard aan is gewoon waardeloos. en dit moet Google bij TY aanpakken(onderhand de enigste site die mij deze irritatie nog opwekt).
Niets zo irritant als afhankelijk te zijn van een te verliezen cookie of de noodzaak voor een crapaccount om zo'n gare instelling te onderdrukken, daar je uiteindelijk bij het benaderen van de tab ook niet raar moet opkijken als je ook nog eens een YT video voorgeschoteld krijg die verre van relevant is omdat het standaard naar de volgende video(s) is gehopt.
Let wel, bij youtube video's worden deze nog wél automatisch afgespeeld. Wat mij vanuit Google's standpunt logisch lijkt.
Hoewel het logisch lijkt, vind ik dat ze hiermee zichzelf te kort doen.

Bij dit soort nieuwe features/settings lijkt het mij zelfs wenselijk om een soort wizard te hebben waarbij je de graag van autoplay eenvoudig kan instellen. Niks vervelender dan "plots" te moeten ontdekken dat het bestaat. Jan Modaal leest immers de changelogs niet..
Weet je dat zeker? Bij mij speelde een YouTube-video niet meer automatisch af na het updaten naar de nieuwste versie.
Wel pas als de pagina in kwestie in de focus staat. Open je een nieuwe tab met YT-video, maar bekijk je de tab niet, begint ie ook niet te spelen.

Misschien niet de beste oplossing, maar wel beter dan een site die begint te spelen, ook al staat ie in een nieuwe tab.
Anoniem: 1322 @C-dude18 april 2018 14:44
Ook CNN autoplayed nog lekker door hoor..
https://edition.cnn.com/2...rth-korea-intl/index.html
Misschien dat deze niet meer automatisch afspeelt wanneer de Tab geen focus heeft?
Om een of andere reden is mijn Chrome al mijn cookies kwijtgeraakt na de upgrade (op Ubuntu).
Ik moest dus overal weer inloggen en al die ellendige cookiewalls wegklikken. Zijn er meer mensen die hier last van hebben?
Gebruik liever gewoon een blocklist in uBlock of AdBlock. Nog een 3th party extensie in je browser is echt niet wat je wil. Het is maar wat vaak voorgekomen dat dit soort extensies opgekocht worden of dat de auteur er een grijs gebied mee betreed.
Gebruik liever gewoon een blocklist in uBlock of AdBlock.
Standaard biedt uBlock Origin geen lijst aan voor cookie walls. Hier kan er één gevonden worden die vroeger wel direct werd aangeboden in uBlock Origin. Een voorbeeld van inbegrepen wat geblokkeerd wordt is de cookiewaarschuwing van T.net.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:23]

Geen last van op macOS 10.13.4. Ben overal gewoon ingelogd na de upgrade.
Hier hetzelfde met Ubuntu Budgie 17.10
Yep, hier ook (Linux Mint). Ik mag overal opnieuw inloggen. Website instellingen die in cookies opgeslagen worden zijn ook weg, dus mag alles en overal opnieuw instellen.
Nu alleen nog hun eigen 'auto-play' functie op youtube uitschakelen en ze zijn goed op weg
Dat auto-play werkt hier voor geen meter. Net even getest bij CNN en video's spelen nog steeds automatisch met geluid. Vet irritant... Mis ik iets?
En wat gebeurt er met webm vp9 video's op de achtergrond van websites? of met video's die op centrale element van de website staan, zoals logo's e.d.? Of geldt het alleen voor video's waar audiotracks bij zitten?
Die exportoptie voor wachtwoorden is dus totaal niet nieuw, dat heb ik pas nog gedaan (middels chrome://flags kon je precies deze optie naar mijn weten al enorm lang aanzetten). Hij is dus hooguit nu zichtbaar by default.

[Reactie gewijzigd door guillaume op 23 juli 2024 08:23]

Google mag sowieso wel wat uitbereiden op die password vault van ze, bijvoorbeeld door middel van een companion app met wat functies, ze lopen m.i. nog mijlenver achter op diensten als Lastpass en dat komt o.a. door het gebrek aan een app die op je telefoon wachtwoorden vanuit je vault in apps kan invoeren.

Ik zit nu elke keer als ik ergens op wil inloggen naar passwords.google.com te browsen om hem vanuit daar te kopieren, dat is omslachtigheid zelve. Het werkt alleen maar deftig op internet pagina's, bezocht vanuit Chrome.

[Reactie gewijzigd door Koffiebarbaar op 23 juli 2024 08:23]

Op dit item kan niet meer gereageerd worden.