Planet Chromium

February 26, 2020

Google Chrome Releases

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 81 (81.0.4044.34) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at February 26, 2020 06:52 PM

Beta Channel Update for Desktop

The beta channel has been updated to 81.0.4044.34 for Windows, Mac, and, Linux.


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Prudhvikumar Bommana
Google Chrome

by Prudhvikumar Bommana (noreply@blogger.com) at February 26, 2020 03:35 PM

February 25, 2020

Google Chrome Releases

Dev Channel Update for Desktop

The Dev channel has been updated to 82.0.4068.4 & 82.0.4068.5 for Windows & Mac, 82.0.4068.4 for Linux.
A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Krishna Govind Google Chrome

by Krishna Govind (noreply@blogger.com) at February 25, 2020 10:41 AM

Stable Channel Update for Desktop

The stable channel has been updated to 80.0.3987.122 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.




A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Security Fixes and Rewards


Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.


This update includes 3 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.


[$5000][1044570] High: Integer overflow in ICU. Reported by André Bargull (with thanks to Jeff Walden from Mozilla) on 2020-01-22
[N/A][1045931] High CVE-2020-6407: Out of bounds memory access in streams. Reported by Sergei Glazunov of Google Project Zero on 2020-01-27


This release also contains:
[N/A][1053604] High CVE-2020-6418: Type confusion in V8. Reported by Clement Lecigne of Google's Threat Analysis Group on 2020-02-18


Google is aware of reports that an exploit for CVE-2020-6418 exists in the wild.


We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.






Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 25, 2020 10:24 AM

February 24, 2020

Google Chrome Releases

Chrome for Android Update

Hi, everyone! We've just released Chrome 80 (80.0.3987.119) for Android: it'll become available on Google Play over the next few weeks.

You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 24, 2020 12:57 PM

February 21, 2020

Monica Dinculescu

Fixing typedoc's generated TOC if your code is using ES6 modules

My one policy about blogging is “write the blog post you wanted to find in the search results”. I spent an inordinate amount of time yesterday trying to get typedoc to only show the docs for the files I’m actually exporting in my library, and didn’t find anything on the internet to help me, so here is the blog post I wanted to read.

The problem

You are working on a JS library. You author your source in TypeScript. You have an index.ts file that exports only some of your source files. You would like your generated docs from typedoc to only have docs for those files (Why? So that people don’t open issues along the lines of “I see the docs for function foo, but I can’t see how to call it, pls export it”. Sweet child, if that function was meant to be public it probably would’ve been. That function is actually 3 spiders in a trench coat).

That is, you would like your Table of Contents to show this: toc only shows 5 entries

and not this: toc shows every file under the sun

Things that aren’t solutions

In the order that I’ve tried them:

  • the --mode modules flag: the word “modules” is a lie here and really just means “under a namespace” not like… ES6 modules (tracking issue)
  • the --excludeNotExported flag: it helps to generate docs for only the exported functions, but not files
  • the -excludePrivate flag: same as above
  • the --exclude flag: this is nice in theory, but I have like 30+ private files that shouldn’t be documented and only like 5 top level exports, so that regex will suck. Also, my experience is that next time someone adds a file they want or don’t want documented they won’t know to add it to this list and we’re back to having a problem
  • the --toc flag. I honestly don’t know what it does, but for me, it did nothing 100% of the time
  • thinking this should presently work in typedoc. Here is the tracking issue and the open PR that might fix it.

My “solution”

I’m less bothered that the docs for the private files get generated at all, and more bothered that they’re linked in the main page TOC and thus discoverable. So my “solution” that “fixes” it is: inject some JavaScript that hides all the files that aren’t exported in the top level index.ts. It’s gross, but it’s good enough (Also: the title of my autobiography).

Disclaimer: This works for for my library (here’s the PR I’m blessing our code with this horror), but for your particular setup it might need some changes. I speak very broken bash, so I probably can’t help you with those changes.

# Variables I have:
# Where your source is. We call the script from a different
# place than the index.ts but maybe you don't.
srcDir="..."

# Where you generate the docs. This could be a /docs folder, or a temp one
# because you're going to push to the GitHub gh-pages branch.
# I don't know what you do, I only know what we do (the latter).
docsDir="..."

# The root index.ts file has a bunch of "export * from './foo';" lines.
# Parse those lines into a space separated list of names. It's ok that
# they're space separated, we'll split them in JS,
# this is all a horror anyway. You might have to touch these regexes, sry.
exports=`sed -n "s/export \* from '.\/\(.*\)';/\1/p" $srcDir/src/index.ts`

# If your theme uses a different td class name than the one below,
# inspecting it and update it in the selector. Also my names had
# a bunch of extra quotes, hence the replacing, yours might not.
# This is why I don't want to maintain this.
scriptToFixTheToc="<script> \
const toc = \"$exports\".split(' '); \
const links = document.querySelectorAll('.tsd-kind-external-module'); \
for (let i = 0; i < links.length; i++) { \
  const name = links[i].textContent.trim().replace(/\"/g, ''); \
  if (toc.indexOf(name) === -1) { \
    links[i].parentNode.removeChild(links[i]); \
  } \
} \
</script>"

# Inject that script in the index.html.
echo $scriptToFixTheToc >> $docsDir/index.html

# Pray.



Like sands through the hourglass so are the hacks of our lives.

February 21, 2020 12:00 AM

February 20, 2020

Google Chrome Releases

Dev Channel Update for Desktop

The Dev channel has been updated to 82.0.4062.3 for Windows, Linux and Mac.
A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Lakshmana Pamarthy Google Chrome

by Lakshmana Pamarthy (noreply@blogger.com) at February 20, 2020 11:30 AM

Stable Channel Update for Desktop

The stable channel has been updated to 80.0.3987.116 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.


A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.

Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 5 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

[N/A][1051017] High CVE-2020-6383: Type confusion in V8. Reported by Sergei Glazunov of Google Project Zero on 2020-02-11
[$7500][1048473] High CVE-2020-6384: Use after free in WebAudio. Reported by David Manouchehri on 2020-02-04
[$5000][1043603] High CVE-2020-6386: Use after free in speech. Reported by Zhe Jin from cdsrc of Qihoo 360 on 2020-01-20

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:
  • [1054478] Various fixes from internal audits, fuzzing and other initiatives




Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at February 20, 2020 11:12 AM

Stable Channel Update for Desktop

The stable channel has been updated to 80.0.3987.106 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.

A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Security Fixes and Rewards
Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.

This update includes 3 security fixes. Please see the Chrome Security Page for more information.

  • [1051555] Various fixes from internal audits, fuzzing and other initiatives

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.



Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at February 20, 2020 11:11 AM

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 81 (81.0.4044.26) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at February 20, 2020 08:41 AM

February 19, 2020

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 81.0.4044.26 for Windows, Mac, and, Linux.

A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Prudhvikumar Bommana
Google Chrome

by Prudhvikumar Bommana (noreply@blogger.com) at February 19, 2020 01:13 PM

Chromium Blog

Chrome 81: Near Field Communications, Augmented Reality, and More

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 81 is beta as of February 13, 2020.

Web NFC for mobile

NFC stands for Near Field Communications, a short-range wireless technology for transmitting small amounts of data, usually between a specialized NFC device and a reader. If you've scanned a badge to enter a building, you may have used used NFC.

Web NFC allows a web app to read and write to NFC tags. This opens new use cases to the web, including providing information about museum exhibits, inventory management, providing information in a conference badge, and many others.

A demonstration of Web NFC cards

Reading and writing are simple operations. You'll need a little instruction for constructing and interpreting payloads, but it's not complicated. Fortunately, we have an article, Interact with NFC devices on the web. Check it out. A few code samples are shown below.

Writing a string to an NFC tag:

if ("NDEFWriter" in window) {
const writer = new NDEFWriter();
await writer.write("Hello world!");
}

Scanning messages from NFC tags:

if ("NDEFReader" in window) {
const reader = new NDEFReader();
await reader.scan();
reader.onreading = ({ message }) => {
console.log(`Message read from a NFC tag: ${message}`);
};
}

Chrome 81 introduces the mobile web to NFC with an origin trial. See the Origin Trials section for information on signing up and for a list of other origin trials starting in this release.

Augmented Reality and Hit Testing

Chrome 81 adds two new immersive features to the web, both designed to support augmented reality. The WebXR Device API, first enabled in Chrome 79, now supports augmented reality. We've also added support for the WebXR Hit Test API, an API for placing objects in a real-world view.

If you've already used the new API to create virtual reality, you'll be happy to know there's very little new to learn to use AR. This is because the spec was designed with the spectrum of immersive experiences in mind. Regardless of the degree of augmentation or virtualization, the application flow is the same. The differences are merely a matter of setting and requesting different properties during object creation.

The WebXR Hit Test API provides a means for an immersive experience to interact with the real world. Specifically, it enables you to place virtual objects on real-world points in a camera view. The image below from one of the Immersive Web Working Group's sample apps illustrates this. The broken blue circle indicates a point returned from the hit test API. If I tap the screen a sunflower will be placed there. The new API captures both the location of a hit test and the orientation of the point that was detected. You'll notice in the image a sunflower has been placed on both the floor and the wall.

If you're completely new to the WebXR Device API, check out our earlier articles, Virtual reality comes to the web and Virtual reality comes to the web, part II. If you're already familiar with entering a WebXR session and constructing a frame loop, then check out our new article on Web AR. Also check out our article on the WebXR Hit Test API.

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.

PointerLock unadjustedMovement

Scripts now have the ability to request unadjusted and unaccelerated mouse movement data when in PointerLock. If unadjustedMovement is set to true, then pointer movements will not be affected by the underlying platform modifications such as mouse acceleration.

Other features in this release

Buffered Flag for Long Tasks

Chrome 81 updates the buffered flag of PerformanceObserver to support long tasks. In particular, this feature provides a way to gain insight into early long tasks for apps or pages that register a PerformanceObserver early.

CSS image-orientation property

Chrome will by default respect EXIF metadata within images indicating desired orientation. The accompanying image-orientation property allows developers to override this behavior.

CSS Color Adjust: color-scheme

A new meta tag and CSS property lets sites opt-in to following the preferred color scheme when rendering UI elements such as default colors of form controls and scrollbars as well as the used values of the CSS system colors. For Chrome 81 only initial color and background are affected.

Exclude Implicit Tracks from grid-template-rows and grid-template-columns Resolved Values

Implicit tracks are now excluded from the resolved values of the grid-template-rows and grid-template-columns. Previously, all tracks were included, whether implicit or explicit.

hrefTranslate attribute on HTMLAnchorElement

The HTMLAnchorElement now has an hrefTranslate attribute, providing the ability for a page to hint to a user agent's translation engine that the destination site of an href should be translated if followed.

IntersectionObserver Document Root

The IntersectionObserver() constructor now takes a Document as the 'root' argument, causing intersections to be calculated against the scrolling viewport of the document. This is primarily targeted towards observers running in an iframe. Previously, there was no way to measure intersection with the scrolling viewport of the iframe's document.

Modernized Form Controls

In version 81, Chrome modernizes the appearance of form controls on Windows, ChromeOS, and Linux while improving their accessibility and touch support. (Mac and Android support are coming soon.) It's hoped that this will reduce the need to build custom form controls. This change is the result of collaboration between Microsoft and Google. For more information, see the recent talk at CDS or the MS blog post. For a closer look at the controls, this page gives an example of all of the elements that changed.

Move onwebkit{animation,transition}XX handlers to GlobalEventHandlers

Until now, the prefixed onwebkit{animation,transition}XX handlers were only available on the Window object in Chrome. They are now on HTMLElement and Document as required by the spec. This fix brings Chrome in line with Gecko and Webkit.

Note: This change is intended to improve interoperability on existing web pages. These handlers are still obsolete so web developers should use the non-refixed versions on new pages.

Position State for Media Session

Adds support for tracking position state in a media session. The position state is a combination of the playback rate, duration, and current playback time. This can then be used by browsers to display position in the UI and with the addition of seeking can support seeking/scrubbing too. For a code sample and demonstration, see our sample.

SubmitEvent

Chrome now supports a SubmitEvent type, an Event subtype which is dispatched on form submission. The SubmitEvent has a submitter property that refers to attributes of the submitter button including the entry data, the formaction attribute, the formenctype attribute, the formmethod attribute, and the formtarget attribute.

Currently, applications are doing their own form submission by calling preventDefault() during onsubmit. This approach has the limitation that the received event does not include the button that triggered the submission.

WebAudio: ConvolverNode.channelCount and channelCountMode

For a ConvolverNode, the channelCount can now be set to 1 or 2. The channelCountMode can be "explicit" or "clamped-max". Previously, a channelCount of 1 was not allowed and neither was a mode of "explicit".

This release also extends ConvolverNode capabilities slightly to allow developers to choose the desired behavior without having to add a GainNode to do the desired mixing.

WebRTC

RTCPeerConnection.onicecandidateerror event changes

The candidateerror event now has an explicit address and port, replacing hostCandidate.

onclosing Event for RTCDataChannel

Adds the onclosing event to the RTCDataChannel object, which signals to the user of a data channel that the other side has started closing the channel. The user agent will continue reading from the queue (if it contains anything) until the queue is empty, but no more data can be sent.

WorkerOptions for shared workers constructor

Adds the WorkerOptions object as the second argument for a shared worker constructor. The previous second argument, a string containing the worker's name is still supported.

WritableStream.close()

WritableStream objects now have a close() method that closes a stream if it is unlocked. This is directly equivalent to getting a writer, using the writer to close the stream, and then unlocking it again.

JavaScript

This version of Chrome incorporates version 8.1 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent changes in the V8 release notes.

Intl.DisplayNames()

The Intl.DisplayNames() object lets an app or script get localized names of language, script, currency codes, and commonly used names of date fields and symbols. This will reduce the size of apps (thereby improving latency), make it easier to build internationalized UI components, reduce translation costs, and provide more consistent translations across the web.

Deprecations, and Removals

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

Deprecation and Remove "basic-card" support Payment Handler

This version of Chrome removes the basic-card polyfill for Payment Request API in iOS Chrome. As a result, the Payment Request API is temporarily disabled in iOS Chrome. For full details, see Rethinking Payment Request for iOS.

Remove supportedType field from BasicCardRequest

Specifying "supportedTypes":[type] parameter for "basic-card" payment method shows cards of only the requested type, which is one of "credit", "debit", or "prepaid".

The card type parameter has been removed from the spec and is now removed from Chrome, because of the difficulty of accurate card type determination. Merchants today must check card type with their PSP, because they cannot trust the card type filter in the browser:

  • Only issuing banks know the card type with certainty and downloadable card type databases have low accuracy, so it's impossible to know accurately the type of the cards stored locally in the browser.
  • The "basic-card" payment method in Chrome no longer shows cards from Google Pay, which may have connections with issuing banks.

Firefox removed "supportedTypes" in version 65.

Remove the <discard> element

Chrome 81 removes the <discard> element. It is only implemented in Chromium, and is thus not possible to use interoperably. For most use cases it can be replaced with a combination of animation of the 'display' property and a removal (JavaScript) callback/event handler.

Remove TLS 1.0 and TLS 1.1

This version of Chrome removes TLS 1.0 and TLS 1.1. TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.
  • TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
  • TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
  • TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and was vulnerable to attacks.
  • TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
  • TLS 1.0 is no longer PCI-DSS compliant.
Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome deprecated these features in version 72 in early 2019.

TLS 1.3 downgrade hardening bypass

TLS 1.3 includes a backwards-compatible hardening measure to strengthen downgrade protections. However, when we shipped TLS 1.3 last year, we had to partially disable this measure due to incompatibilities with some non-compliant TLS-terminating proxies. Chrome currently implements the hardening measure for certificates which chain up to known roots, but allows a bypass for certificates chaining up to unknown roots. We intend to enable it for all connections.

Downgrade protection mitigates the security impact of the various legacy options we retain for compatibility. This means user's connections are more secure and, when security vulnerabilities are discovered, it is less of a scramble to respond to them. (That, in turn, means fewer broken sites for users down the road.) This also aligns with RFC 8446.

by Chromium Blog (noreply@blogger.com) at February 19, 2020 07:54 AM

Monica Dinculescu

monica.css

Back in the day when I worked on Polymer I got used to relying on a bunch of useful CSS classes that at the time we called iron-flex-layout. They were there partly because flexbox was a sadness on IE and you needed to say everything 3 times to maybe get it right twice, and add some very special flex-basis: 0.000000001px “bug fixes” that tbh nobody should ever have to write by hand. But they were also there because it’s kind of nice to say <div class="horizontal"> and for it to just work.

Some years later, it’s now 2020, and flexbox is really good everywhere! We don’t need iron-flex-layout anymore, but tbh I still want to say <div class="horizontal"> and for it to just work.

I know there are tons of CSS frameworks out there like tachyons that can do this for me, but most of these frameworks do too much for me. I don’t work on large projects that need design systems, and I don’t want every possible padding and margin and colour and flexbox configuration in the world. I just want the ones that I know I end up using in every project. So here is monica.css: my very own CSS framework, which I copy paste at the beginning of every CSS file and take it from there. It’s already minified and bundled (because you copy pasted it) so dare I say: fast loading and efficient? 🙃

* {box-sizing: border-box}
[hidden] {display: none !important}
[disabled] {pointer-events:none; opacity: 0.3}
.horizontal {display: flex; flex-direction: row; justify-content: space-between}
.vertical {display: flex; flex-direction: column}
.center {justify-content: center; align-items: center}
.flex {flex: 1}
html {
  --spacing-xs: 8px;
  --spacing: 24px;
  --spacing-s: 12px;
  --spacing-m: 36px;
}

February 19, 2020 12:00 AM

February 18, 2020

Google Chrome Releases

Chrome for Android Update

Hi, everyone! We've just released Chrome 80 (80.0.3987.117) for Android: it'll become available on Google Play over the next few weeks.

You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 18, 2020 05:13 PM

February 14, 2020

Google Chrome Releases

Dev Channel Update for Desktop

The Dev channel has been updated to 82.0.4056.3 for Windows and Mac. Linux platform will be updated next week.
A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Lakshmana Pamarthy Google Chrome

by Lakshmana Pamarthy (noreply@blogger.com) at February 14, 2020 11:53 AM

February 13, 2020

Google Chrome Releases

Stable Channel Update for Desktop

The Chrome team is delighted to announce the promotion of Chrome 80 to the stable channel for Windows, Mac and Linux. This will roll out over the coming days/weeks.

Chrome 80.0.3987.87 contains a number of fixes and improvements -- a list of changes is available in the log. Watch out for upcoming Chrome and Chromium blog posts about new features and big efforts delivered in 80.
Security Fixes and Rewards

Note: Access to bug details and links may be kept restricted until a majority of users are updated with a fix. We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.


This update includes 56 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

[$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 Jordan Pryde from the 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

We would also like to thank all security researchers that worked with us during the development cycle to prevent security bugs from ever reaching the stable channel.

As usual, our ongoing internal security work was responsible for a wide range of fixes:
  • [1048330] Various fixes from internal audits, fuzzing and other initiatives






Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Thank you,

Srinivas Sista

by Srinivas Sista (noreply@blogger.com) at February 13, 2020 02:48 PM

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 81 (81.0.4044.18) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at February 13, 2020 02:00 PM

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 81 to the beta channel for Windows, Mac and Linux. Chrome 81.0.4044.17 contains our usual under-the-hood performance and stability tweaks, but there are also some cool new features to explore - please head to the Chromium blog to learn more!


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Prudhvikumar Bommana
Google Chrome

by Prudhvikumar Bommana (noreply@blogger.com) at February 13, 2020 12:15 PM

February 12, 2020

Google Chrome Releases

Dev Channel Update for Desktop

The Dev channel has been updated to 81.0.4044.17 for Windows, Mac and Linux.
A partial list of changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.
Prudhvikumar Bommana Google Chrome

by Prudhvikumar Bommana (noreply@blogger.com) at February 12, 2020 11:22 AM

February 11, 2020

Google Chrome Releases

Chrome for Android Update

Hi, everyone! We've just released Chrome 80 (80.0.3987.99) for Android: it'll become available on Google Play over the next few weeks.

You can see a full list of the changes in the Git log. If you find a new issue, please let us know by filing a bug.


Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 11, 2020 09:12 PM

Chrome Beta for Android Update

Hi everyone! We've just released Chrome Beta 80 (80.0.3987.99) for Android: it's now available on Google Play.

You can see a partial list of the changes in the Git log. For details on new features, check out the Chromium blog, and for details on web platform updates, check here.

If you find a new issue, please let us know by filing a bug.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 11, 2020 12:37 PM

Stable Channel Update for Desktop

The stable channel has been updated to 80.0.3987.100 for Windows, Mac, and Linux, which will roll out over the coming days/weeks.

A list of all changes is available in the log. Interested in switching release channels? Find out how. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.


Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at February 11, 2020 10:38 AM

Beta Channel Update for Desktop

The beta channel has been updated to 80.0.3987.100 for Windows, Mac, and, Linux.


A full list of changes in this build is available in the log. Interested in switching release channels?  Find out how here. If you find a new issue, please let us know by filing a bug. The community help forum is also a great place to reach out for help or learn about common issues.



Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at February 11, 2020 10:00 AM

February 07, 2020

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 80.0.3987.89 (Platform version: 12739.60.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. Changes can be viewed here.


If you find new issues, please let us know by visiting our forum or filing a bug. Interested in switching channels? Find out how. You can submit feedback using ‘Report an issue...’ in the Chrome menu (3 vertical dots in the upper right corner of the browser).

Daniel Gagnon
Google Chrome

by Daniel Gagnon (noreply@blogger.com) at February 07, 2020 11:01 AM

February 06, 2020

Chromium Blog

Protecting users from insecure downloads in Google Chrome

Today we’re announcing that Chrome will gradually ensure that secure (HTTPS) pages only download secure files. In a series of steps outlined below, we’ll start blocking "mixed content downloads" (non-HTTPS downloads started on secure pages). This move follows a plan we announced last year to start blocking all insecure subresources on secure pages.

Insecurely-downloaded files are a risk to users' security and privacy. For instance, insecurely-downloaded programs can be swapped out for malware by attackers, and eavesdroppers can read users' insecurely-downloaded bank statements. To address these risks, we plan to eventually remove support for insecure downloads in Chrome.

As a first step, we are focusing on insecure downloads started on secure pages. These cases are especially concerning because Chrome currently gives no indication to the user that their privacy and security are at risk.

Starting in Chrome 82 (to be released April 2020), Chrome will gradually start warning on, and later blocking, these mixed content downloads. File types that pose the most risk to users (e.g., executables) will be impacted first, with subsequent releases covering more file types. This gradual rollout is designed to mitigate the worst risks quickly, provide developers an opportunity to update sites, and minimize how many warnings Chrome users have to see.

We plan to roll out restrictions on mixed content downloads on desktop platforms (Windows, macOS, Chrome OS and Linux) first. Our plan for desktop platforms is as follows:


Diagram of when warnings will take affect

  • In Chrome 81 (released March 2020) and later:
    • Chrome will print a console message warning about all mixed content downloads.
  • In Chrome 82 (released April 2020):
    • Chrome will warn on mixed content downloads of executables (e.g. .exe).
  • In Chrome 83 (released June 2020):
    • Chrome will block mixed content executables.
    • Chrome will warn on mixed content archives (.zip) and disk images (.iso).
  • In Chrome 84 (released August 2020):
    • Chrome will block mixed content executables, archives and disk images.
    • Chrome will warn on all other mixed content downloads except image, audio, video and text formats.
  • In Chrome 85 (released September 2020):
    • Chrome will warn on mixed content downloads of images, audio, video, and text.
    • Chrome will block all other mixed content downloads.
  • In Chrome 86 (released October 2020) and beyond, Chrome will block all mixed content downloads.



Example of a potential warning



Chrome will delay the rollout for Android and iOS users by one release, starting warnings in Chrome 83. Mobile platforms have better native protection against malicious files, and this delay will give developers a head-start towards updating their sites before impacting mobile users. 

Developers can prevent users from ever seeing a download warning by ensuring that downloads only use HTTPS. In the current version of Chrome Canary, or in Chrome 81 once released, developers can activate a warning on all mixed content downloads for testing by enabling the "Treat risky downloads over insecure connections as active mixed content" flag at chrome://flags/#treat-unsafe-downloads-as-active-content

Enterprise and education customers can disable blocking on a per-site basis via the existing InsecureContentAllowedForUrls policy by adding a pattern matching the page requesting the download. 

In the future, we expect to further restrict insecure downloads in Chrome. We encourage developers to fully migrate to HTTPS to avoid future restrictions and fully protect their users. Developers with questions are welcome to email us at security-dev@chromium.org. 

Posted by Joe DeBlasio, Chrome Security team


by Chromium Blog (noreply@blogger.com) at February 06, 2020 10:00 AM