Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Software-update: Google Chrome 86.0.4240.75

Google Chrome logo (80 pix) Google heeft versie 86 van zijn webbrowser Chrome uitgebracht. Google Chrome is beschikbaar voor Windows, Linux en macOS. Er zijn ook versies voor Android en iOS, maar die volgen een iets ander releaseschema. In versie 86 is het onder meer eenvoudiger om uitgelekte wachtwoorden te wijzigen, zijn accusparende maatregelen toegevoegd voor tabs die op de achtergrond draaien en geeft het een waarschuwing wanneer een onveilig formulier wordt ingevuld op een https-pagina. De belangrijkste veranderingen die in versie 86 zijn aangebracht, naast de gebruikelijke bug- en security fixes, zijn hieronder voor je op een rijtje gezet.

CSS Pseudo-Class: focus-visible and the Quick Focus Highlight

For users who rely on a keyboard or similar assistive technology to navigate the web, the focus indicator is a crucial visual affordance. To improve both the user and developer experience of working with focus, Chrome 86 is introducing two features.

The first is a CSS selector, :focus-visible, which lets a developer opt-in to the same heuristic the browser uses when it's deciding whether to display a default focus indicator.

The second is a user setting called Quick Focus Highlight. When enabled, this setting causes an additional focus indicator to appear over the active element. Importantly, this indicator will be visible even if the page has disabled focus styles with CSS and it causes any :focus or :focus-visible styles to always be displayed. For details, see Giving users and developers more control over focus.


Note: The origin trial for this feature was originally announced as starting in Chrome 85. That timeline changed.

There is a long tail of human interface devices (HIDs) that are too new, too old, or too uncommon to be accessible by systems' device drivers. The WebHID API solves this by providing a way to implement device-specific logic in JavaScript.

An HID is one that takes input from or provides output to humans. Examples of devices include keyboards, pointing devices (mice, touchscreens, etc.), and gamepads.

The inability to access uncommon or unusual HID devices is particularly painful when it comes to gamepad support. Gamepad inputs and outputs are not well standardized and web browsers often require custom logic for specific devices. This is unsustainable and results in poor support for the long tail of older and uncommon devices.

We're working on an article to show you how to use the new API. In the meantime, we've found some demos from a few eager engineers that you can use to try the new API. To see those demos, check out Human interface devices on the web: a few quick examples. The Origin Trials section has information on signing up and a list of other origin trials starting in this release. This origin trial is expected to run through Chrome 87 in January 2021.

Origin Trials

This version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

New Origin Trials Cross-Screen Window Placement

Adds new screen information APIs and makes incremental improvements to existing window placement APIs, allowing web applications to offer compelling multi-screen experiences.

The existing window.screen property offers a limited view of available screen space, while window placement functions are generally restricted to the current screen. This feature unlocks modern multi-screen capabilities for web applications.

battery-savings Meta Tag

Adds a meta tag allowing a site to recommend measures for the user agent to apply in order to save battery life and optimize CPU usage. Websites that are known to have high CPU or battery costs may want to request that the UA optimize for CPU or battery, even if the user has not requested it. Most modern operating systems also have battery saving features that activate either when the battery is low or the user wishes to save battery. Ideally web sites should be able to respect these settings. Sites may wish to advise the user agent on which strategies work best for the site in these situations.

Secure Payment Confirmation

Secure payment confirmation augments the payment authentication experience on the web with the help of the Web Authentication API. The feature adds a new PaymentCredential credential type to the Credential Management API, which allows a relying party such as a bank to create a PublicKeyCredential that can be queried by any merchant origin as part of an online checkout via the Payment Request API using the proposed secure-payment-confirmation payment method.

This feature enables a consistent, low friction, strong authentication experience using platform authenticators. Strong authentication with the user's bank is becoming a requirement for online payments in many regions, including the European Union. The new feature provides a better user experience and stronger security than existing solutions.

Cross-Origin-Opener-Policy Reporting API

Adds a reporting API to help developers deploy cross-origin opener policy (COOP) on their websites. In addition to reporting breakages when COOP is enforced, it proves a report-only mode that reports potential breakages that would have happened had COOP been enforced. To register for the origin trial, follow the link above. For more information, see Making your website "cross-origin isolated" using COOP and COEP.

Completed Origin Trials

The following features, previously in a Chrome origin trial, are now enabled by default.

Native File System

The new Native File System API enables developers to build powerful web apps that interact with files on the user's local device such as IDEs, photo and video editors, text editors, and more. After a user grants access, this API allows web apps to read or save changes directly to files and folders on the user's device. It does all this by invoking the platform's own open and save dialog boxes. The image below shows a web page invoked using the open dialog box on Mac.

To learn more, see sample code, and a text editor demonstration app, see The Native File System API: Simplifying access to local files for details.

Note: The API surface is changed considerably from what was available in the origin trial. Differences are explained in detail in the spec repo. In the coming weeks, watch the article listed above for a full explanation of how to use the production version of the API.

Other Features in This Release Altitude and Azimuth for PointerEvents v3

Adds Altitude and Azimuth angles to PointerEvents. Adds tiltX and tiltY to altitude and azimuth transformation and altitude and azimuth to tiltX and tiltY transformation depending on which pair is available from the device. These angles are those commonly measured by devices. Altitude and azimuth can be calculated using trigonometry from tiltX, tiltY. From a hardware perspective it is easier and less expensive to measure tiltX and tiltY.

From a stylus app perspective altitude and azimuth makes more sense and is more intuitive for users. Using tiltX and tiltY requires a developer to visualize the intersection angle between two imaginary planes, while azimuth and altitude are easier to visualize just by looking at the pen and the screen surface.

Adding azimuth and altitude makes the API more intuitive. Providing conversion between tiltX and tiltY and altitude and azimuth and vice versa allows for backwards compatibility with apps using tiltX and tiltY (even if newer devices might only return altitude and azimuth).

A Well-Known URL for Changing Passwords

Note: this was erroneously listed as shipping in Chrome 86. It is actually shipping in Chrome 87.

Websites can set a well-known URL for changing passwords (for example, /.well-known/change-password). This URL's purpose is to redirect users to the change password page in order for them to modify their passwords quickly. Chrome leverages this URL to help users change their passwords when it detects a saved, compromised password. For more information, see Help users change passwords easily by adding a well-known URL for changing passwords.

Change Encoding of Space Character when URLs are Computed by Custom Protocol Handlers

The navigator.registerProtocolHandler() handler now replaces spaces with "%20" instead of "+". This makes Chrome consistent with other browsers such as Firefox.

CSS ::marker Pseudo-Element

Adds a pseudo-element for customizing numbers and bullets for <ul> and <ol> elements. This change lets developers control the color, size, bullet shape, and number type.

Document-Policy Header

Document Policy restricts the surface area of the web platform on a per-document basis, similar to iframe sandboxing, but more flexibly. It can do things like:

  • Restrict the use of poorly-performing images.
  • Disable slow synchronous JavaScript APIs.
  • Configure iframe, image, or script loading styles.
  • Restrict overall document sizes or network usage.
  • Restrict patterns which cause page re-layout.

Additionally, the header allows sites to opt out of fragment and text-fragment scrolling on load as a privacy mitigation for the scroll-to-text-fragment feature. This is the first part of the Document Policy API to ship.

EME persistent-usage-record Session

Adds a new MediaKeySessionType named "persistent-usage-record session", for which the license and keys are not persisted and for which a record of key usage is persisted when the keys available within the session are destroyed. This feature may help content providers understand how decryption keys are used for purposes like fraud detection.


A FetchEvent dispatched to a service worker is in a loading pipeline, which is performance sensitive. The new FetchEvent.handled property returns a promise that resolves when a response is returned from a service worker to its client. This enables a service worker to delay tasks that can only run after responses are complete.


Adds a property to determine whether the pitch of an audio or video element should be preserved when adjusting the playback rate. This feature is wanted for creative purposes (for example, pitch-shifting in "DJ deck" style applications). It also prevents the introduction of artifacts from pitch-preserving algorithms at playback speeds very close to 1.00. It is already supported by Safari and Firefox.

Imperative Shadow DOM Distribution API

Web developers can now explicitly set the assigned nodes for a slot element. This solves two problems with Shadow DOM v1:

  • Web developers must specify a slot attribute for every one of a shadow host's children (except for elements for the default slot).
  • Component creators can't change the slotting behavior based on conditions.

For information on how the new API solves these issues, see the Imperative Shadow DOM Distribution API explainer.

Move window.location.fragmentDirective

The window.location.fragmentDirective property has been moved to document.fragmentDirective. This is a change to the text fragments feature.

New Display Values for the <fieldset> Element

The <fieldset> element now supports 'inline-grid', 'grid', 'inline-flex', and 'flex' keywords for the CSS 'display' property.

ParentNode.replaceChildren() Method

Adds a method to replace all children of the ParentNode with the passed-in nodes. Previously, there are a couple different ways to replace a node's children with a new set of nodes including:

  • Using node.innerHTML and node.append() to clear and replace all child nodes.
  • Using node.removeChild() and node.append() in a loop.
Safelist Distributed Web Schemes for registerProtocolHandler()

Chrome has extended the list of URL schemes that can be overridden via registerProtocolHandler() to include cabal, dat, did, dweb, ethereum, hyper, ipfs, ipns, and ssb. Extending the list to include decentralized web protocols allows resolution of links to generic entities independently of the website or gateway that's providing access to it. For more information, see Programmable Custom Protocol Handlers at are we distributed yet?

text/html Support for the Asynchronous Clipboard API

The Asynchronous Clipboard API currently does not support the text/html format. Chrome 86 adds support for copying and pasting HTML from the clipboard. The HTML is sanitized when it is read and written to the clipboard. The purpose of this change is to allow use cases such as:

  • Web editors, to copy and paste rich text with images and links.
  • Remote desktop applications, to synchronize text/html payloads across devices.

This is also intended to help the replacement of document.execCommand() for copy and paste functionality.

VP9 for macOS Big Sur

The VP9 video codec is now available on macOS Big Sur whenever it's supported in the underlying hardware. If developers use the Media Capabilities API to detect playback smoothness and power efficiency, the logic in their player should automatically start preferring VP9 at higher resolutions without any action on their part. To take full advantage of this feature, developers should encode their VP9 files in multiple resolutions to accommodate varying user bandwidths and connections.

WebRTC Insertable Streams

Enables the insertion of user-defined processing steps in the encoding and decoding of a WebRTC MediaStreamTrack. This allows applications to insert custom data processing. An important use case this supports is end-to-end encryption of the encoded data transferred between RTCPeerConnections via an intermediate server.

Deprecations, and Removals

This version of Chrome introduces the deprecations and removals listed below. Visit for lists of current deprecations and previous removals.

Remove WebComponents v0 from WebView

Web Components v0 was removed from desktop and Android in Chrome 80. Chromium 86 removes them from WebView. This removal includes Custom Elements v0, Shadow DOM v0, and HTML Imports.

Deprecate FTP Support

Chrome is deprecating and removing support for FTP URLs. The current FTP implementation in Google Chrome has no support for encrypted connections (FTPS), or proxies. Usage of FTP in the browser is sufficiently low that it is no longer viable to invest in improving the existing FTP client. In addition, more capable FTP clients are available on all affected platforms.

Chrome 72 and later removed support for fetching document subresources over FTP and rendering of top level FTP resources. Currently navigating to FTP URLs results in showing a directory listing or a download depending on the type of resource. A bug in Google Chrome 74 and later resulted in dropping support for accessing FTP URLs over HTTP proxies. Proxy support for FTP was removed entirely in Google Chrome 76.

The remaining capabilities of Google Chrome's FTP implementation are restricted to either displaying a directory listing or downloading a resource over unencrypted connections.

Deprecation of support will follow this timeline:

Chrome 86

FTP is still enabled by default for most users, but turned off for pre-release channels (Canary and Beta) and will be experimentally turned off for one percent of stable users. In this version you can re-enable it from the command line using either the --enable-ftp command line flag or the --enable-features=FtpProtocol flag.

Chrome 87

FTP support will be disabled by default for fifty percent of users but can be enabled using the flags listed above.

Chrome 88

FTP support will be disabled.txt

Google Chrome

Versienummer 86.0.4240.75
Releasestatus Final
Besturingssystemen Windows 7, Linux, macOS, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019
Website Google
Licentietype Freeware

Reacties (31)

Wijzig sortering
Kan iemand mij eens uitleggen hoe ze altijd aan die belachelijke versienummers komen? Tis net of ik naar een Nier Automata titel aan het kijken ben.
Dat is ooit eens uitgelegd door Google. Was even zoeken, maar heb het gevonden.

MAJOR and MINOR may get updated with any significant Google Chrome release (Beta or Stable update). MAJOR must get updated for any backwards incompatible user data change (since this data survives updates).
BUILD must get updated whenever a release candidate is built from the current trunk (at least weekly for Dev channel release candidates). The BUILD number is an ever-increasing number representing a point in time of the Chromium trunk.
PATCH must get updated whenever a release candidate is built from the BUILD branch.

MAJOR and MINOR track updates to the Google Chrome stable channel. In this sense, they reflect a scheduling or marketing decision rather than anything about the code itself. These numbers are generally only significant for tracking milestones. In the event that we get a significant release vehicle for Chromium code other than Google Chrome, we can revisit the versioning scheme.

The BUILD and PATCH numbers together are the canonical representation of what code is in a given release. The BUILD number is always increasing as the source code trunk advances, so build 180 is always newer code than build 177. The PATCH number is always increasing for a given BUILD. Developers and testers generally refer to an instance of the product (Chromium or Google Chrome) as BUILD.PATCH. It is the shortest unambiguous name for a build.
Vind ik ook altijd bijzonder. Voor mijn eigen hobbyproject had ik ooit ook een ingewikkeld versienummersysteem, maar toen zag ik van een andere tool het supersimpele 1-getalsysteem (versie 1, versie 2, versie 3) en ik was gelijk verkocht. Mijn eigen project zit dus nu op versie 24. Bevalt prima; superduidelijk en supersimpel.
Naast de eerdere reacties zie je dergelijke versienummers ook meer in situaties waarin er gebruik gemaakt wordt van een periodieke release cycle. In dergelijke releases zitten vaak meer dan 1 wijzigingen (features, bugfixes etc.) in de software. Software producten die een CD release cycle gebruiken zullen ook veel vaker een major-only versie nummering hanteren.
Ben ik de enigste die zich afvraagt wat we moeten met een WebHID API? Het is leuk dat Google wil gamen, maar ik zit er bepaald niet op te wachten dat mijn browser via JS toegang krijgt tot mijn interface devices. En dat is dus niet alleen je toetsenbord en muis, maar de hele lijst die onder "Human Interface Devices" staat in device manager.

Webbrowsers zouden naar mijn mening idealiter in een afgesloten sandbox moeten draaien, zonder enige tot hardware of onderliggende systeem. Er is te veel rommel op het www om dat allemaal toe te staan. Op deze manier wordt het wel heel makkelijk gemaakt om keylogger te fabriceren als je met JS via een gedocumenteerde API user inputs kunt afvangen. Of omgekeerd, outputs te genereren om te misbruiken voor controle over het systeem.
Ik weet niet hoe enig je bent, dus of je de enigste bent kan ik je niet antwoorden. Tot nu toe ben je in ieder geval wel de enige die het vraagt, als dat is wat je bedoeld.

Je zal expliciet toegang moeten geven tot je apparaten als een webpagina hierom vraagt.
To mitigate abuse, a device will not be made available to the page until the user has granted explicit access. Access must first be requested by the page and will be granted once the user has selected the device from a chooser displaying all available devices. Once a page has been granted access, an indicator will be displayed to indicate the device is in use.

Het kan zijn dat er ongewenste dingen gebeuren. Maar je hebt natuurlijk toestemming gegeven tot je HID. Dan maakt het niet uit dat de toepassing in een webbrowser draait (die er tenminste nog om vraagt). Want als de toepassing als applicatie beschikbaar was, dan had die alsnog toegang. Je wilt immers toch gebruik maken van die applicatie.

[Reactie gewijzigd door xFeverr op 7 oktober 2020 09:02]

Lolbroek. :) Maar je hebt gelijk over het woordgebruik.

Inhoudelijk: er is een wezenlijk verschil. Lokale programma's is iets waar je zelf controle over hebt. Remote JS niet. Het zou zo maar kunnen zijn dat jij toestemming geeft voor een bepaalde site voor gebruik hiervoor, waar vervolgens later de JS wordt aangepast voor meer louche toepassingen. Dan wordt er of geen toestemming meer gevraagd, of gelijk ok geklikt omdat je de site kent. Hoe dan ook, er is geen pop up die jou gaat vertellen wat er in de JS staat en wat het doet. Die toestemming is dus een wassen neus omdat je niet weet waar je toestemming op geeft en je niet kunt controleren of de achterliggende JS verandert is of wat het allemaal op de achtergrond doet. Het is een 'feature' die smeekt om misbruikt te worden. Dit is het tegenovergestelde van security by design en heel, heel slecht.
Ik ben het er niet mee eens. Over lokale programma's heb je juist nog minder controle. Chrome is dus een lokaal programma, en daar heb je dus geen controle over. Als Chrome het kan, kan elke applicatie het. Alleen is Chrome nog zo netjes om het je te vragen als een pagina toegang nodig heeft.

Daarnaast heeft de Javascript in je browser enkel toegang heeft tot de API's die je browser levert. Deze Javascipt-scripts zullen dan ook altijd beperkter zijn dan een lokaal programma.

Je zou kunnen discussiëren of de drempel tot toegang tot je HID te laag is. Of dat dit er überhaupt moet zijn. Maar als het er is en er is toestemming, dan is het niet schadelijker of met minder controle dan een lokale applicatie.
Het is trouwens enige en niet enigste O-)
als dat is wat je bedoeld.
bedoelt :+
Wellicht voor bijv. steering wheel support voor Stadia?
Ik kan vanalles verzinnen waarom het leuk zou kunnen zijn, maar geen enkele waarom het nodig is. Waarom een security issue introduceren onder het mom van een feature die je vervolgens weer moet gaan beschermen tegen misbruik?
Tsja, wat 'nodig' en wat 'leuk' is aan browserfunctionaliteit zal per persoon verschillen.
Nou nee. "required" of " must have" en "nice to have" zijn prima te definieren en weinig open voor discussie. Het volgen van bepaalde webstandaarden is een must have/required, het ondersteunen van game controllers voor webbased games is dat objectief niet.

De core functionaliteit van een web browser is het (correct) renderen van web pagina's, hopelijk volgens de W3C vastgestelde standaard. Alles wat hieraan niet direct iets toevoegt is voor een web browser per definitie niet een must have en het beste geval een nice te have.

Hoe dan ook hoort bij elke feature afgevraagd te worden of dit een security risico met zich meebrengt, En iedereen kan hoog of laag springen, maar directe toegang geven tot hardware aan een programma waar een van de primaire taken is het van een willekeurige, onbekende bron ophalen van en lokaal uitvoeren van scripts is een big no-no. Dan heb je naar mijn mening gewoon schijt aan beveiliging van je gebruikers als je dat doet, ongeacht hoe goed en veilig je denkt het te kunnen implementeren
Ik wil heel graag bredere controller support voor Chrome want gamen via de browser is voor mij een fundamenteel onderdeel geworden van waarvoor ik die browser gebruik.
Geen FTP meer? Dat zuigt want ik download nog wel eens een iso via ftp en zit er niet echt op te wachten dat ik dan weer naar een ander programma moet overstappen. Kleine moeite maar weer een extra onnodige handeling
Connecties zijn zo stabiel en snel tegenwoordig, dat de additionele functies van FTP t.o.v. HTTP, zoals hervat download vanaf x, steeds minder relevant worden.

Wat is jou in jouw geval het voordeel van de FTP-download t.o.v. een over h2 (HTTPS)?
omdat er gewoon geen http mirror is. meeste linux of bsd isos zijn via ftp te bereiken
Hervat download vanaf X is ook gewoon beschikbaar in HTTP, met de Range header..

Als de server hier correct op reageert, krijgt de client enkel het aangevraagde bereik aan bytes terug.
Ah, dus is er eigenlijk geen reden meer om FTP in de lucht te houden :-)

Nu hopen voor @matty___ dat zijn favoriete distro's snel ook http-mirrors krijgen.
Kan iemand mij uitleggen wat "gecomprimenteerde wachtwoorden" zijn?
Wachtwoorden waarvan bekend is dat ze ergens gelekt zijn.
Bijv :
Ik denk dat hij vooral doelt op het woord dat niet bestaat. Heb het als opmerking in het spelfoutentopic gemeld.
Nouja, er staat een t te weinig in, maar om daardoor te doen alsof een woord niet te begrijpen is is wel wat bijzonder ;)
Eh nee. Zoek maar op Google; gecomprimenteerde wordt automatisch veranderd naar gecompromitteerde. Dat is letterlijk een heel andere schrijfwijze dan alleen een missende t ;)

Edit: Wel jammer dat dit als "ongewenst" wordt gemodereerd waar een correcte moderatie gewoon offtopic/irrelevant zou moeten zijn. Jammerdebammer weer.

[Reactie gewijzigd door Merethil op 7 oktober 2020 08:31]

Ah ja ik las er over heen. Rustig aan, ik val je niet persoonlijk aan.

En tja, qua moderatie is deze hele thread niks anders dan -1, het is gewoon irrelevant en spam want het hoort hier niet ;) (inclusief mijn berichten hoor)
Ik denk dat je er meer in leest dan hoe ik het bedoel; ik zette mijn eerste post neer met de juiste bedoelingen en als iemand dan verkeerd leest en me terecht probeert te wijzen ga ik daar weer op in :+
Excuses als het aanvallend overkwam ;)
Ik zeg letterlijk een post erboven dat ik hem in dat topic heb gemeld :P
Dat werkte ook prima, want het is aangepast. En nee, het gaat me niet om karma maar om mismoderatie. Ongewenst lijkt mij vooral te gaan om zaken die écht ongewenst zijn; dus flaming, baiting, random URLs die mensen spammen etc.

Maar goed, het is dus aangepast :)

Op dit item kan niet meer gereageerd worden.

Microsoft Xbox Series X LG CX Google Pixel 5 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack,, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True