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.”

Quieter notifications

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.”

Security fixes

Chrome 80 implements 56 security fixes. The following were found by external researchers:

[$5000][1034394] High CVE-2020-6381: Integer overflow in JavaScript. Reported by The UK’s National Cyber Security Centre (NCSC) on 2019-12-09

[$2000][1031909] High CVE-2020-6382: Type Confusion in JavaScript. Reported by Soyeon Park and Wen Xu from SSLab, Gatech on 2019-12-08

[$500][1020745] High CVE-2019-18197: Multiple vulnerabilities in XML. Reported by BlackBerry Security Incident Response Team on 2019-11-01

[$500][1042700] High CVE-2019-19926: Inappropriate implementation in SQLite. Reported by Richard Lorenz, SAP on 2020-01-16

[$N/A][1035399] High CVE-2020-6385: Insufficient policy enforcement in storage. Reported by Sergei Glazunov of Google Project Zero on 2019-12-18

[$N/A][1038863] High CVE-2019-19880, CVE-2019-19925: Multiple vulnerabilities in SQLite. Reported by Richard Lorenz, SAP on 2020-01-03

[$N/A][1042535] High CVE-2020-6387: Out of bounds write in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2020-01-16

[$N/A][1042879] 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][1042933] High CVE-2020-6389: Out of bounds write in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2020-01-16

[$N/A][1045874] High CVE-2020-6390: Out of bounds memory access in streams. Reported by Sergei Glazunov of Google Project Zero on 2020-01-27

[$10000][1017871] Medium CVE-2020-6391: Insufficient validation of untrusted input in Blink. Reported by Michał Bentkowski of Securitum on 2019-10-24

[$5000][1030411] Medium CVE-2020-6392: Insufficient policy enforcement in extensions. Reported by Microsoft Edge Team on 2019-12-03

[$5000][1035058] Medium CVE-2020-6393: Insufficient policy enforcement in Blink. Reported by Mark Amery on 2019-12-17

[$3000][1014371] Medium CVE-2020-6394: Insufficient policy enforcement in Blink. Reported by Phil Freo on 2019-10-15

[$3000][1022855] Medium CVE-2020-6395: Out of bounds read in JavaScript. Reported by Pierre Langlois from Arm on 2019-11-08

[$3000][1035271] Medium CVE-2020-6396: Inappropriate implementation in Skia. Reported by William Luc Ritchie on 2019-12-18

[$2000][1027408] Medium CVE-2020-6397: Incorrect security UI in sharing. Reported by Khalil Zhani on 2019-11-22

[$2000][1032090] Medium CVE-2020-6398: Uninitialized use in PDFium. Reported by pdknsk on 2019-12-09

[$2000][1039869] Medium CVE-2020-6399: Insufficient policy enforcement in AppCache. Reported by Luan Herrera (@lbherrera_) on 2020-01-07

[$1000][1038036] Medium CVE-2020-6400: Inappropriate implementation in CORS. Reported by Takashi Yoneuchi (@y0n3uchy) on 2019-12-27

[$500][1017707] Medium CVE-2020-6401: Insufficient validation of untrusted input in Omnibox. Reported by Tzachy Horesh on 2019-10-24

[$500][1029375] Medium CVE-2020-6402: Insufficient policy enforcement in downloads. Reported by Vladimir Metnew (@vladimir_metnew) on 2019-11-28

[$TBD][1006012] Medium CVE-2020-6403: Incorrect security UI in Omnibox. Reported by Khalil Zhani on 2019-09-19

[$N/A][1024256] Medium CVE-2020-6404: Inappropriate implementation in Blink. Reported by kanchi on 2019-11-13

[$N/A][1042145] Medium CVE-2020-6405: Out of bounds read in SQLite. Reported by Yongheng Chen(Ne0) & Rui Zhong(zr33) on 2020-01-15

[$N/A][1042254] Medium CVE-2020-6406: Use after free in audio. Reported by Sergei Glazunov of Google Project Zero on 2020-01-15

[$N/A][1042578] Medium CVE-2019-19923: Out of bounds memory access in SQLite. Reported by Richard Lorenz, SAP on 2020-01-16

[$1000][1026546] Low CVE-2020-6408: Insufficient policy enforcement in CORS. Reported by Zhong Zhaochen of andsecurity.cn on 2019-11-20

[$1000][1037889] Low CVE-2020-6409: Inappropriate implementation in Omnibox. Reported by Divagar S and Bharathi V from Karya Technologies on 2019-12-26

[$500][881675] Low CVE-2020-6410: Insufficient policy enforcement in navigation. Reported by evi1m0 of Bilibili Security Team on 2018-09-07

[$500][929711] Low CVE-2020-6411: Insufficient validation of untrusted input in Omnibox. Reported by Khalil Zhani on 2019-02-07

[$N/A][968505] 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][1005713] Low CVE-2020-6413: Inappropriate implementation in Blink. Reported by Michał Bentkowski of Securitum on 2019-09-19

[$N/A][1021855] Low CVE-2020-6414: Insufficient policy enforcement in Safe Browsing. Reported by Lijo A.T on 2019-11-06

[$N/A][1029576] Low CVE-2020-6415: Inappropriate implementation in JavaScript. Reported by Avihay Cohen @ SeraphicAlgorithms on 2019-11-30

[$N/A][1031895] Low CVE-2020-6416: Insufficient data validation in streams. Reported by Woojin Oh(@pwn_expoit) of STEALIEN on 2019-12-08

[$N/A][1033824] Low CVE-2020-6417: Inappropriate implementation in installer. Reported by Renato “Wrath” Moraes and Altieres “FallenHawk” Rohr on 2019-12-13

[1048330] 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.

Developer features

Chrome 80 introduces ECMAScript Modules in Web Workers. Module Workers support standard JavaScript imports and dynamic import for lazy-loading without blocking worker execution. This is useful since 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.

Chrome 80 also brings an update to the V8 JavaScript engine. Version 8.0 (affectionately called V8 V8) includes pointer compression, optimization of higher-order builtins, and JavaScript features like optional chaining and nullish coalescing. Check out the full changelog for more information.

Other developer features in this release include:

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.