Google today launched Chrome 80 for Windows, Mac, Linux, Android, and iOS. The release includes autoupgrading mixed content to HTTPS, SameSite cookie changes, quieter permission UI for notifications, and more developer features. This release thus beefs up security for the world’s most popular browser and begins cracking down on cross-site cookies. You can update to the latest version now using Chrome’s built-in updater or download it directly from google.com/chrome.
With over 1 billion users, Chrome is both a browser and a major platform that web developers must consider. In fact, with Chrome’s regular additions and changes, developers have to stay on top of everything available — as well as what has been deprecated or removed. Among other things, Chrome 80 has started deprecating FTP support by disabling it by default for non-enterprise clients.
Autoupgrading mixed content
Google has been coaxing developers to avoid HTTP in a bid to get the web to HTTPS. While Chrome users spend over 90% of their browsing time on HTTPS, Google isn’t done yet. The latest push came in October, when Google laid out its plan for mixed content.
HTTPS is a more secure version of the HTTP protocol used on the internet to connect users to websites. Secure connections are widely considered a necessary measure to decrease the risk of users being vulnerable to content injection (which can result in eavesdropping, man-in-the-middle attacks, and other data modification). Data is kept secure from third parties, and users can be more confident they are communicating with the correct website.
In December, Chrome 79 introduced a setting to unblock mixed scripts, iframes, and other types of content that the browser blocks by default. You can toggle this setting (lock icon on HTTPS pages => Site Settings).
Now, Chrome 80 autoupgrades mixed audio and video resources in HTTPS sites by rewriting URLs to HTTPS without falling back to HTTP when secure content is not available. If they fail to load over HTTPS, Chrome will block them by default. Mixed images are still allowed to load, but they will cause Chrome to mark the page as “Not Secure” in the omnibox.
In Chrome 81, coming in April, mixed images will be autoupgraded to HTTPS. If they fail to load over HTTPS, Chrome will block them by default.
Google’s ultimate goal is to ensure HTTPS pages in Chrome can only load secure HTTPS subresources. If you’re a developer looking to clean up your mixed content, check out the Content Security Policy, Lighthouse, and this HTTPS guide.
SameSite cookie changes
In May 2016, Chrome 51 introduced the SameSite attribute to allow sites to declare whether cookies should be restricted to a same-site (first-party) context. The hope was this would mitigate cross-site request forgeries (CSRF).
Chrome 80 will begin enforcing a new secure-by-default cookie classification system, treating cookies that have no declared SameSite value as
SameSite=Lax cookies. Only cookies set as
SameSite=None; Secure will be available in third-party contexts, provided they are being accessed from secure connections. Chrome 80 thus removes the following backward compatible behaviors:
- Disallow defaulting of SameSite attribute to ‘None’: The SameSite attribute now defaults to Lax meaning your cookies are only available to other sites from top-level navigations. As originally implemented in Chrome, the SameSite attribute defaults to None, which was essentially the Web’s status quo. Cookies have valid cross-site use cases, but if a site owner did not previously want to allow cross-site cookie use there was no way to declare such an intent or enforce it.
- Value ‘None’ no longer allowed on insecure contexts: Chrome now requires that when the SameSite attribute is set to None, that the Secure attribute must also be present. The Secure attribute requires that the attached cookie can only be transmitted over a secure protocol such as HTTPS.
It’s worth noting that enforcement of the new cookie classification system in Chrome 80 will begin in two weeks “with a small population of users, gradually increasing over time.” Cross-site cookies that are missing the required settings will then effectively be blocked. Exact timing updates will be available on the SameSite Updates page.
Update on April 3: Due to the coronavirus crisis, Google has paused the SameSite cookie changes and plans to resume enforcement sometime over the summer. “While most of the web ecosystem was prepared for this change, we want to ensure stability for websites providing essential services including banking, online groceries, government services and healthcare that facilitate our daily life during this time,” the company wrote. “As we roll back enforcement, organizations, users and sites should see no disruption.”
Chrome 80 attempts to make unsolicited permission requests less annoying. Chrome 80 will now sometimes show a quieter notification permission UI. Users can opt-in to the new UI manually (Settings => Site Settings => Notifications) and it will also be automatically enabled under two conditions: for users who typically block notification permission requests and on sites with very low opt-in rates. Later this year, Google plans to enable additional enforcement against “abusive websites using web notifications for ads, malware, or deceptive purposes.”
The “quieter UI” is available on both desktop and mobile. Ironically, the first time the UI is presented to the user, it will be accompanied by an in-product help dialog.
Google recommends that developers follow best practices for requesting the notification permission from users. Specifically, the company says:
Websites that ask users to sign up for web notifications when they first arrive often have very low accept rates. Instead, we recommend that websites wait until users understand the context and see benefit in receiving notifications before prompting for the permission. Some websites display a pre-prompt in the content area before triggering the native permission prompt. This approach is also not recommended if it interrupts the user journey: sites that request the permission at contextually relevant moments enjoy lower bounce and higher conversion rates.
Google also offers Permission UX documentation.
Contacts Picker API and Content Indexing API
Back in September with the release of Chrome 77, Google introduced Origin Trials, which let you try new features and provide feedback on usability, practicality, and effectiveness to the web standards community. The first new feature was the Contact Picker API that lets users select entries from their contact list and share limited details of the selected entries with a website. Chrome 80 now ships the Contact Picker API, ending the first Origin Trial. At the same time, Chrome 80 starts a new Origin Trial that adds features to the API. Currently, only the contact’s name, email address, and telephone number are available via
ContactsManager.getProperties(). The new Origin Trial adds the user’s mailing address (‘address’) and image (‘icon’).
Chrome 80 also includes another Origin Trial: the Content Indexing API, which provides metadata about content that your web app has already cached. It stores URLs for HTML documents that display stored media, plus lets you add, list, and remove resources. While Progressive Web Apps (PWAs) can store content such as images, videos, articles, and more for offline access using the Cache Storage API or IndexedDB, that content isn’t discoverable. Now it is and can even be used if the network is unavailable.
Android and iOS
Chrome 80 for Android is rolling out slowly on Google Play. The changelog should be familiar based on what you’ve read above:
- Quieter notifications: You can see fewer notification requests with a new permission option.
- SameSite cookies: By default, cookies are treated as same-site only.
- Secure media: Insecure audio and video on secure pages are automatically upgraded to secure connections.
Chrome 80 for iOS is rolling out on Apple’s App Store. The changelog has just one entry: “When you start a search in the address bar, you’ll see top suggestions served locally on your device, even in Incognito mode.”
Chrome 80 implements 56 security fixes. The following were found by external researchers:
- [$500] High CVE-2019-18197: Multiple vulnerabilities in XML. Reported by BlackBerry Security Incident Response Team on 2019-11-01
- [$500] High CVE-2019-19926: Inappropriate implementation in SQLite. Reported by Richard Lorenz, SAP on 2020-01-16
- [$N/A] High CVE-2020-6385: Insufficient policy enforcement in storage. Reported by Sergei Glazunov of Google Project Zero on 2019-12-18
- [$N/A] High CVE-2019-19880, CVE-2019-19925: Multiple vulnerabilities in SQLite. Reported by Richard Lorenz, SAP on 2020-01-03
- [$N/A] High CVE-2020-6387: Out of bounds write in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2020-01-16
- [$N/A] High CVE-2020-6388: Out of bounds memory access in WebAudio. Reported by Sergei Glazunov of Google Project Zero on 2020-01-16
- [$N/A] High CVE-2020-6389: Out of bounds write in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2020-01-16
- [$N/A] High CVE-2020-6390: Out of bounds memory access in streams. Reported by Sergei Glazunov of Google Project Zero on 2020-01-27
- [$10000] Medium CVE-2020-6391: Insufficient validation of untrusted input in Blink. Reported by Michał Bentkowski of Securitum on 2019-10-24
- [$5000] Medium CVE-2020-6392: Insufficient policy enforcement in extensions. Reported by Microsoft Edge Team on 2019-12-03
- [$5000] Medium CVE-2020-6393: Insufficient policy enforcement in Blink. Reported by Mark Amery on 2019-12-17
- [$3000] Medium CVE-2020-6394: Insufficient policy enforcement in Blink. Reported by Phil Freo on 2019-10-15
- [$3000] Medium CVE-2020-6396: Inappropriate implementation in Skia. Reported by William Luc Ritchie on 2019-12-18
- [$2000] Medium CVE-2020-6397: Incorrect security UI in sharing. Reported by Khalil Zhani on 2019-11-22
- [$2000] Medium CVE-2020-6398: Uninitialized use in PDFium. Reported by pdknsk on 2019-12-09
- [$2000] Medium CVE-2020-6399: Insufficient policy enforcement in AppCache. Reported by Luan Herrera (@lbherrera_) on 2020-01-07
- [$1000] Medium CVE-2020-6400: Inappropriate implementation in CORS. Reported by Takashi Yoneuchi (@y0n3uchy) on 2019-12-27
- [$500] Medium CVE-2020-6401: Insufficient validation of untrusted input in Omnibox. Reported by Tzachy Horesh on 2019-10-24
- [$500] Medium CVE-2020-6402: Insufficient policy enforcement in downloads. Reported by Vladimir Metnew (@vladimir_metnew) on 2019-11-28
- [$TBD] Medium CVE-2020-6403: Incorrect security UI in Omnibox. Reported by Khalil Zhani on 2019-09-19
- [$N/A] Medium CVE-2020-6404: Inappropriate implementation in Blink. Reported by kanchi on 2019-11-13
- [$N/A] Medium CVE-2020-6405: Out of bounds read in SQLite. Reported by Yongheng Chen(Ne0) & Rui Zhong(zr33) on 2020-01-15
- [$N/A] Medium CVE-2020-6406: Use after free in audio. Reported by Sergei Glazunov of Google Project Zero on 2020-01-15
- [$N/A] Medium CVE-2019-19923: Out of bounds memory access in SQLite. Reported by Richard Lorenz, SAP on 2020-01-16
- [$1000] Low CVE-2020-6408: Insufficient policy enforcement in CORS. Reported by Zhong Zhaochen of andsecurity.cn on 2019-11-20
- [$1000] Low CVE-2020-6409: Inappropriate implementation in Omnibox. Reported by Divagar S and Bharathi V from Karya Technologies on 2019-12-26
- [$500] Low CVE-2020-6410: Insufficient policy enforcement in navigation. Reported by evi1m0 of Bilibili Security Team on 2018-09-07
- [$500] Low CVE-2020-6411: Insufficient validation of untrusted input in Omnibox. Reported by Khalil Zhani on 2019-02-07
- [$N/A] Low CVE-2020-6412: Insufficient validation of untrusted input in Omnibox. Reported by Zihan Zheng (@zzh1996) of University of Science and Technology of China on 2019-05-30
- [$N/A] Low CVE-2020-6413: Inappropriate implementation in Blink. Reported by Michał Bentkowski of Securitum on 2019-09-19
- [$N/A] Low CVE-2020-6414: Insufficient policy enforcement in Safe Browsing. Reported by Lijo A.T on 2019-11-06
- [$N/A] Low CVE-2020-6416: Insufficient data validation in streams. Reported by Woojin Oh(@pwn_expoit) of STEALIEN on 2019-12-08
- [$N/A] Low CVE-2020-6417: Inappropriate implementation in installer. Reported by Renato “Wrath” Moraes and Altieres “FallenHawk” Rohr on 2019-12-13
-  Various fixes from internal audits, fuzzing and other initiatives
Google thus spent at least $48,000 in bug bounties for this release. As always, the security fixes alone should be enough incentive for you to upgrade.
importScripts() executes scripts in the global scope, which can lead to name collisions and its associated problems, and it blocks execution of the worker while it fetches and evaluates the imported script.
Other developer features in this release include:
DecompressionStream. It is possible to compress stream data without this feature, but common libraries like zlib are complex to use. Compression streams make it easy for developers to compress data, and avoid the need to bundle a compressor with an application.
- CSS Improvements: The
line-break: anywheredeclaration allows soft wrapping around every typographic character unit, including around any punctuation character or preserved spaces, or in the middles of words. It disregards any prohibition against line breaks, even those introduced by characters with the GL, WJ, or ZWJ character class (see UAX 14) or mandated by the word-break property. The
overflow-wrap: anywheredeclaration allows an otherwise unbreakable sequence of characters to be broken at an arbitrary point if there are no otherwise-acceptable break points in a line. Additionally, soft wrap opportunities introduced by
anywhereare considered when calculating min-content intrinsic sizes.
- Decoding Encrypted Media: The capabilities of
MediaCapabilities.decodingInfo()are now available for encrypted media. The
decodingInfo()method (available in multiple browsers) allows websites to get more information about the decoding abilities of the client. This enables more informed selection of media streams for the user, enabling scenarios such as smoothly and power-efficiently decoding a video for the available bandwidth and screen size.
- Delegating Shipping Address and Contact Information in Web Payments: The Payment Handler API now lets the browser delegate handling of the shipping address and payer’s contact information to Payment Handlers. Delegating collection of the shipping address and contact information to payment handlers can lead to better user experiences because the payment app may have more accurate information than the browser. It can also reduce the checkout steps by one since the browser can show the payment handler window directly rather than showing the payment sheet UI first to collect shipping address and/or payer’s contact information.
- Fetch Metadata Destination header: Chrome now supports the
Sec-Fetch-DestHTTP request header which exposes a request’s destination to a server, providing it with information on which to base security decisions. The spec provides a list of its possible values.
- HTMLVideoElement.getVideoPlaybackQuality(): This method retrieves information about video playback performance. Such information may be used to alter bitrate, framerate, or resolution, either upward or downward, to provide a better user experience.
- Offscreen Canvases Now Support getTransform(): The
getTransform(). Like its
CanvasRenderingContext2Dcounterpart, this method lets you retrieve the transformation matrix that is currently applied to the context.
- Support for SVG in favicons: Chrome now supports using SVG images as favicons. Scalable formats for favicons reduce the resources for a website or app.
- Text URL Fragments: Users or authors can now link to a specific portion of a page using a text fragment provided in a URL. When the page is loaded, the browser highlights the text and scrolls the fragment into view.
For a full rundown of what’s new, check out the Chrome 80 milestone hotlist.
Google releases a new version of its browser every six weeks or so. Chrome 81 will arrive in mid-March.