Planet Chromium

February 14, 2019

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 73.0.3683.39 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.



Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at February 14, 2019 02:18 PM

February 13, 2019

Google Chrome Releases

Stable Channel Update for Desktop

The stable channel has been updated to 72.0.3626.109 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.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at February 13, 2019 02:35 PM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 73.0.3683.32 (Platform version: 11647.28.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.

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

Cindy Bayless
Google Chrome

by Cindy Bayless (noreply@blogger.com) at February 13, 2019 12:59 PM

February 12, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 74.0.3702.0 for Windows, Mac & 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.
Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at February 12, 2019 05:23 PM

Chromium Blog

Introducing a Trusted Web Activity for Android

A Trusted Web Activity (TWA) displays a full screen Chrome browser inside of an Android app with no browser UI. Although Android apps routinely include web content using a Chrome Custom Tab (CCT) or WebView, a TWA offers unique advantages when you need Chrome’s performance and features in your app in full screen mode.


In this post I’ll introduce you to TWAs, review suggested use cases and link to resources to get you started.



What’s different about a Trusted Web Activity?  


A Trusted Web Activity runs a Chrome browser full screen in an Android app, meaning there is no browser UI visible in the app, including the URL bar. This is a powerful capability so we need to verify that the app and the site belong to the same developer - hence ‘Trusted’. To verify that the app and the site opened in the TWA belong to the same developer, a TWA uses Digital Asset Links to certify ownership.


Because a TWA is a special case of a Chrome Custom Tab (CCT), it has access to all Chrome features and functionality including many not available to a WebView. If you’re not familiar with Chrome Custom Tabs, this article provides a complete overview. Some of the features of a TWA not available in a WebView include web push notifications, background sync, Chrome form autofill, Media Source Extensions (MSE) and the Sharing API.


Just like a CCT, a website loaded in a TWA shares stored data with the Chrome browser, including cookies. This implies shared session state, which for most sites means that if a user has previously signed into your website in Chrome they will also be signed into the TWA.



What can I use a TWA for?  


TWAs are great for including full screen web content in an Android application where you need Chrome features not available in a WebView or if shared origin storage with the Chrome browser makes your user journey easier.


An example of this is an e-commerce site where product pages are implemented in native views but the checkout flow takes place on the website. By using a TWA your app will have Chrome’s performance and can use Chrome’s one tap signup and automatic form filling features.




Trusted Web Activity Criteria


All content in TWAs must comply with Play store policy including policies for payments in-app purchases and other digital goods.


App users expect a great experience on their device. To ensure the quality of experience TWAs must meet PWA installability criteria and load fast. Loading speed is measured using Lighthouse and web content in TWAs must achieve a performance score of 80. Lighthouse is an open-source, automated tool for auditing performance & progressive web apps and is useful both as a benchmark and to help you build better websites.

As with any Play app, additional quality criteria may apply in the future. Apps which fail to meet TWA quality requirements or Play store policy may be denied entry or delisted.




Trusted Web Activity content security and version availability


The content of a TWA is protected and cannot be read or modified by the enclosing application. That means state can only be shared from the app to the TWA when it is initialized by passing in query string parameters and it is not possible to insert content into the TWA from the Android application.


TWAs are available on devices running Android KitKat or newer (over 95% of Android devices) with Chrome installed. If Chrome is installed but is out of date, for example due to user disabled Chrome updates, a Chrome Custom Tab is automatically substituted for the TWA.



Your first Trusted Web Activity

Getting started documentation & example code for TWAs is in development and will be released soon. In the meantime reference documentation is included below.  



Reference


Posted by Peter Mclachlan, Product Manager

by Chrome Blog (noreply@blogger.com) at February 12, 2019 03:29 AM

February 11, 2019

Google Chrome Releases

Chrome for Android Update

Good news, everyone!  Chrome 72 (72.0.3626.105) for Android has been released and will be available on Google Play over the course of the next few weeks. This release includes stability and performance improvements.

A list of the changes in this build is available in the Git log.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 11, 2019 02:53 PM

Chromium Blog

Chrome 73 Beta: Constructable stylesheets, a new RegExp function, and passive mouse events

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, macOS, and Windows. View a complete list of the features in Chrome 73 on ChromeStatus.com. Chrome 73 is beta as of February 8, 2019.

Constructable stylesheets

It's long been possible to dynamically create a stylesheet by attaching it directly to a <style> element's sheet property. This comes with problems including a flash of unstyled content and sometimes the bloat of duplicate CSS rules. New methods on the CSSStyleSheet interface add a programmatic way to add stylesheets, eliminating the old method's problems.

Constructable stylesheets let you define shared CSS styles and apply them to multiple shadow roots or to the document object. This is referred to as adopting. Updates to a shared style sheet are applied everywhere it's been adopted. Adopting a stylesheet is fast. Constructable stylesheets are useful in many use cases including theme sharing between components, preloading stylesheets without DOM injection, and more.

Instead of a new API, stylesheets are constructed imperatively with the replace() and replaceSync() methods as shown below.

const sheet = new CSSStyleSheet();

// replace all styles synchronously:
sheet.replaceSync('a { color: red; }');

// replace all styles, allowing external resources:
sheet.replace('@import url("styles.css")')
    .then(sheet => {
        console.log('Styles loaded successfully');
    })
    .catch(err => {
        console.error('Failed to load:', err);
    });

To learn more, check out our article or try the sample.

String.prototype.matchAll()

A new regular expression matching method is being added to String.prototype. The matchAll() function provides a more complete set of matches than String.prototype.match() does. To understand the new function, first consider the following regular expression code:

const regex = /t(e)(st(\d?))/g;
const string = 'test1test2';

Calling string.match(regex) returns an array that contains only complete matches, in this case 'test1' and 'test2'. What about those capturing groups? I can get the first set, those related to 'test1' if I remove the g flag. Getting the rest currently requires writing additional code. It would be nice if I didn't need to.

The specification authors reached the same conclusion and created matchAll(), which has just landed in Chrome. And instead of returning the limited results just described, matchAll() returns an iterable object and contains a few convenience properties.

To learn more about this method read our article on developers.google.com. For more about what's new in JavaScript for Chrome, head over to v8.dev.

Passive Mousewheel listeners

Scrolling responsiveness is important enough to user engagement that Chrome has been working to improve scrolling through event behavior. A best practice for event listeners is that if they don't call preventDefault(), then they need to be registered as passive (by passing {passive: true} to addEVentListener()). Non-passive events are blocking since the browser has to wait for them to finish in case preventDefault() was called.

Unnecessarily blocking event listeners happen often enough that in Chrome 56, we changed touchstart and touchmove that are registered on root targets to be passive by default. This allows the browser to safely perform scrolling and zooming without being blocked on listeners. Starting in Chrome 73, the wheel and mousewheel event listeners behave the same way, making the following lines of code equivalent:

window.addEventListener("wheel", func);
window.addEventListener("wheel", func, {passive: true} );

For more background and a few stats on change, read Making wheel events passive by default.

Other features in this release

Cross-Origin resource policy

Cross-Origin-Resource-Policy response header allows http servers to ask the browser to prevent cross-origin or cross-site embedding of the returned resource. This is complementary to the Cross-Origin Read Blocking feature and is especially valuable for resources not covered by CORB (which only protects HTML, XML and JSON).

Cross-Origin-Resource-Policy is currently the only way to protect images against Spectre attacks or against compromised renderers.
CSS redirects are cross-origin

To align with the specification, stylesheets that (a) failed to load due to network error, or (b) loaded via a redirect from cross-origin back to same-origin are considered cross-origin.

document.visibilityState set to “hidden” when WebContents is occluded

Thanks to the WebContents Occlusion feature in Chromium, the Page Visibility API will now accurately reflect the visibility state of web pages, especially when they are occluded. In other words, the document.visibilityState value will be “hidden” when the browser tab or window is covered by one or more window.

The WebContents Occlusion feature is supported only on Chrome OS and macOS at this time. Windows support is in progress.

DOMMatrixReadOnly.scaleNonUniform()

The scaleNonUniform() function post-multiplies a non-uniform scale transformation on the current matrix and returns the resulting matrix. It is being re-added to support legacy compatibility with SVGMatrix. Non-uniform scaling is a transformation in which at least one of the scaling factors is different from the others. For example, non-uniform scaling might turn a rectangle into a square or a parallelogram.

EME extension: HDCP policy check

Applications now have the ability to query whether a certain HDCP policy can be enforced so that playback can be started at the optimum resolution for the best user experience. A sample is available for developers who want to try it.

GamePad API: GamepadButton touched attribute

The GamePad API now provides the touched state of a gamepad button, which indicates whether a finger is on a button independent of whether it's being pressed.

imagesrcset and imagesizes attributes on link rel=preload

The <link> element now supports imagesrcset and imagesizes properties to correspond to srcset and sizes attributes of HTMLImageElement. To use them, the <link> element must include the preload and image keywords as shown below.

<link rel="preload" as="image" href="pic400.jpg" imagesizes="100vw"
imagesrcset="pic400.jpg 400w, pic800.jpg 800w, pic1600.jpg 1600w">

Implicit root scroller

Implicit root scroller allows viewport-filling scrollers (iframes, divs) to perform document-level scrolling, i.e. show/hide URL bar, overscroll glow, rotation anchoring, etc.. This feature doesn't have an API so it's not on a standards track. Chrome will try to determine if a page is mainly contained in a non-document scroller and attempt to delegate its document-scrolling-UX to that scroller.

This is an implicit version of the previously proposed rootScrollers API.

::part pseudo element on shadow hosts

Chrome now supports the ::part() pseudo-element on shadow hosts, allowing shadow hosts to selectively expose chosen elements from their shadow tree to the outside page for styling purposes.

PerformanceObserver.supportedEntryTypes

PerformanceObserver.supportedEntryTypes provides a way to feature-detect the PerformanceEntry types that are implemented in a web browser. For example, a developer running this in Chrome could get something like this in the console:

["longtask", "mark", "measure", "navigation", "paint", "resource"]

Use the response URL as the base URL for CSS and XSLT stylesheets


On the web, URLs are usually relative to the document's base URL. That means, if the page is /hello/ and contains <img src="world.jpg">, the image is loaded from /hello/world.jpg.

There are a couple of exceptions to this, the most common of which is CSS. Within stylesheets, URLs (e.g. for background images) are relative to the stylesheet's "response URL".

The "response" distinction is important. If the page contains <link rel="stylesheet" href="/styles.css">, and /styles.css redirects to /foo/styles.css, URLs in the stylesheet will be relative to /foo/styles.css. In this case the request URL is different to the response URL, and it's the response URL that's used as the base URL.

With a service worker in the middle, Chrome didn't handle this correctly. It would use the request URL as the base URL for CSS. This is fixed in Chrome 73. Chrome will correctly use the response URL.

This change applies to the following resource types:

XHR: Use the response URL for responseURL and documents

XHR's responseURL property should provide the URL of the response.

In many cases, the request and response URLs are the same, but service workers can choose to return a response from elsewhere. Redirects also cause the request and response URLs to be different.

If the XHR request was intercepted by a service worker, Chrome would incorrectly set responseURL to the request URL. This is fixed in Chrome 73. Chrome will correctly set responseURL to the response URL.

WebRTC updates

RTCConfiguration.offerExtmapAllowMixed

A boolean property has been added to RTCConfiguration.offerExtmapAllowMixed() to enable the extmap-allow-mixed attribute in a session description protocol (SDP) offer.

The SDP attribute extmap-allow-mixed, as defined in RFC8285, will be included in the SDP offer if this property is set to true. The SDP attribute extmap-allow-mixed is supported from Chrome 71, but due to backwards compatibility problems it was not included in the SDP offer by default.

This property is purely transitional. Initially it will be off by default. We hope to change the default to on when enough clients have updated their code. We hope that eventually backwards compatibility will not be needed and we can remove it completely.

RTCRtpReceiver.getParameters()

The new RTCRtpReceiver.getParameters() method returns the RTCRtpReceiver object's track decoding parameters, which includes the codec and RTP header lists negotiated for the call, the RTCP information, and the layer count.

This method is an analog to RTCRtpSender.getParameters() and presents similar information for a call, but on the receiver side. It does not allow modification of the call's parameters.

RTCRtpReceiver.getSynchronizationSources()

The new RTCRtpReceiver.getSynchronizationSources() method returns the latest playout timestamps of RTP packets for audio and video receivers. This is useful for determining in real time which streams are active, such as for the use case of audio meters or prioritizing displaying active participant streams in the UI.

Turn RTCRtpContributingSource from an interface into a dictionary

The specification requires RTCRtpContributingSource to be a dictionary, but it was previously shipped as an interface. With this change RTCRtpContributingSource will no longer have a prototype and getContributingSources() will create a new set of objects with each call.

Rename Atomics.wake() to Atomics.notify()

The Atomics.wake() method is being renamed Atomics.notify(). This is a low-level function to wake a Worker that has been suspended via Atomics.wait(). This conforms to a specification change made to alleviate confusion created by the similarity of the names wait and wake.

Transform list interpolation

Chrome has improved how CSS transforms are handled to reduce cases where a matrix interpolation fallback is used. An interpolation is an intermediate transformation. Sometimes interpretation of the CSS rule requires falling back to a matrix to accomplish the interpolation, and this can produce visual results other than what the web developer intends. To mitigate this, the specification was changed to reduce the number of situations when this can occur.

Interoperability improvements

Spec-compliant shadow blur-radius

Historically, Blink's blur-radius interpretation has been at odds with both the CSS and Canvas2D specifications in that Blink shadows cover about half the expected area.

With this change Gaussian blur sigma is now computed as one-half the blur-radius, as mandated by the specification. Blink's shadow implementation now matches FireFox and Safari.

Remove isomorphic decoding of URL fragment identifier

When Chrome opens a URL with a fragment id, it decodes %xx and applies isomorphic-decode to it, then tries to find an element with the decoding result as an ID in some cases. For example, if a user opens example.com/#%F8%C0, Chrome does the following:
  1. It searches the page for an element with id="%F8%C0".
  2. If it’s not found, it searches the page for an element with id="&#xF8;&#xC0;".
No other browsers do this, and it's not defined by the standard. Starting in version 73, Chrome no longer does this either.

Deprecations, and Removals

Remove EXPLAIN and REINDEX support in WebSQL

The output ofEXPLAIN is not guaranteed to be stable over SQLite versions, so developers cannot rely on it. REINDEX is only useful when collation sequence definitions change, and Chrome only uses the built-in collation sequences. Both features are now removed.

Deprecate 'drive-by downloads' in sandboxed iframes

Chrome has deprecated downloads in sandboxed iframes that lack a user gesture ('drive-by downloads'), though this restriction could be lifted via an allow-downloads-without-user-activation keyword in the sandbox attribute list. This allows content providers to restrict malicious or abusive downloads.

Downloads can bring security vulnerabilities to a system. Even though additional security checks are done in Chrome and the operating system, we feel blocking downloads in sandboxed iframes also fits the general thought behind the sandbox. Apart from security concerns, it would be a more pleasant user experience for a click to trigger a download on the same page, compared with downloads started automatically when landing at a new page, or started non-spontaneously after the click.

Removal is expected in Chrome 74.

by Chrome Blog (noreply@blogger.com) at February 11, 2019 08:09 AM

February 08, 2019

Google Chrome Releases

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 73 (73.0.3683.27) for Android has been released and is available in Google Play.  A partial list of the changes in this build is available in the Git log. Details on new features is available on the Chromium blog, and developers should check out our updates related to the web platform here.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at February 08, 2019 04:57 PM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 72.0.3626.97 (Platform version: 11316.123.0, 11316.123.1) for most Chrome OS devices. This build contains a number of bug fixes and security updates. Systems will be receiving updates over the next several days.

New Features
  • Addition of a page about touch gestures in the built-in ChromeVox screen reader tutorial
  • Chrome browser has been optimized for touchscreen devices in tablet mode
  • External storage access for Android apps using direct /storage and MediaStore APIs
  • App shortcuts for Android apps are now searchable in the launcher. Users can find an app shortcut by long pressing or right-clicking on an Android app.
  • Policies added to manage print job attributes for native printing including simple/duplex printing and color/B&W printing
  • Picture in Picture (PiP) now available for Chrome sites
  • Within the ChromeVox screen reader, added a setting in the ChromeVox options page to read anything under the mouse cursor
  • Files saved via Backup and Sync on Drive now available in Files app under My Drive/Computers
Security Improvements

  • Shill, the network manager for Chrome OS, has been put in a sandbox and no longer runs as the root user on the system. This security hardening measure helps protect users in the case of networking-related security vulnerabilities, such as one that resulted in persistent device compromise in 2016.

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

David McMahon
Google Chrome

by djmm (noreply@blogger.com) at February 08, 2019 12:27 PM

Beta Channel Update for Desktop

The Chrome team is excited to announce the promotion of Chrome 73 to the beta channel for Windows, Mac and Linux. Chrome 73.0.3683.27 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.


Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at February 08, 2019 12:10 PM

Stable Channel Update for Desktop

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

Chrome 72.0.3626.81 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 72.



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 58 security fixes. Below, we highlight fixes that were contributed by external researchers. Please see the Chrome Security Page for more information.

[$7500][914497] Critical CVE-2019-5754: Inappropriate implementation in QUIC Networking. Reported by Klzgrad on 2018-12-12
[$N/A][906043] High CVE-2019-5782:  Inappropriate implementation in V8. Reported by Qixun Zhao of Qihoo 360 Vulcan Team via Tianfu Cup on 2018-11-16

[$5000][913296] High CVE-2019-5755: Inappropriate implementation in V8. Reported by Jay Bosamiya on 2018-12-10
[$5000][895152] High CVE-2019-5756: Use after free in PDFium. Reported by Anonymous on 2018-10-14
[$3000][915469] High CVE-2019-5757: Type Confusion in SVG. Reported by Alexandru Pitis, Microsoft Browser Vulnerability Research on 2018-12-15
[$3000][913970] High CVE-2019-5758: Use after free in Blink. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2018-12-11
[$3000][912211] High CVE-2019-5759: Use after free in HTML select elements. Reported by Almog Benin on 2018-12-05
[$3000][912074] High CVE-2019-5760: Use after free in WebRTC. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2018-12-05
[$3000][904714] High CVE-2019-5761: Use after free in SwiftShader. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2018-11-13
[$3000][900552] High CVE-2019-5762: Use after free in PDFium. Reported by Anonymous on 2018-10-31
[$1000][914731] High CVE-2019-5763: Insufficient validation of untrusted input in V8. Reported by Guang Gong of Alpha Team, Qihoo 360 on 2018-12-13
[$1000][913246] High CVE-2019-5764: Use after free in WebRTC. Reported by Eyal Itkin from Check Point Software Technologies on 2018-12-09
[$N/A][922677] High: Use after free in FileAPI. Reported by Mark Brand of Google Project Zero on 2019-01-16
[$TBD][922627] High CVE-2019-5765: Insufficient policy enforcement in the browser. Reported by Sergey Toshin (@bagipro) on 2019-01-16
[$N/A][916080] High: Use after free in Mojo interface. Reported by Mark Brand of Google Project Zero on 2018-12-18
[$N/A][912947] High: Use after free in Payments. Reported by Mark Brand of Google Project Zero on 2018-12-07
[$N/A][912520] High: Use after free in Mojo interface. Reported by Mark Brand of Google Project Zero on 2018-12-06
[$N/A][899689] High CVE-2019-5785: Stack buffer overflow in Skia. Reported by Ivan Fratric of Google Project Zero on 2018-10-29
[$4000][907047] Medium CVE-2019-5766: Insufficient policy enforcement in Canvas. Reported by David Erceg on 2018-11-20
[$2000][902427] Medium CVE-2019-5767: Incorrect security UI in WebAPKs. Reported by Haoran Lu, Yifan Zhang, Luyi Xing, and Xiaojing Liao from Indiana University Bloomington on 2018-11-06
[$2000][805557] Medium CVE-2019-5768: Insufficient policy enforcement in DevTools. Reported by Rob Wu on 2018-01-24
[$1000][913975] Medium CVE-2019-5769: Insufficient validation of untrusted input in Blink. Reported by Guy Eshel on 2018-12-11
[$1000][908749] Medium CVE-2019-5770: Heap buffer overflow in WebGL. Reported by  hemidallt@ on 2018-11-27
[$1000][904265] Medium CVE-2019-5771: Heap buffer overflow in SwiftShader. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2018-11-12
[$500][908292] Medium CVE-2019-5772: Use after free in PDFium. Reported by Zhen Zhou of NSFOCUS Security Team on 2018-11-26
[$N/A][917668] Medium CVE-2019-5773: Insufficient data validation in IndexedDB. Reported by Yongke Wang of Tencent's Xuanwu Lab (xlab.tencent.com) on 2018-12-24
[$N/A][904182] Medium CVE-2019-5774: Insufficient validation of untrusted input in SafeBrowsing. Reported by Junghwan Kang (ultract) and Juno Im on 2018-11-11
[$N/A][896722] Medium CVE-2019-5775: Insufficient policy enforcement in Omnibox. Reported by evi1m0 of Bilibili Security Team on 2018-10-18
[$N/A][863663] Medium CVE-2019-5776: Insufficient policy enforcement in Omnibox. Reported by Lnyas Zhang on 2018-07-14
[$N/A][849421] Medium CVE-2019-5777: Insufficient policy enforcement in Omnibox. Reported by Khalil Zhani on 2018-06-04
[$500][918470] Low CVE-2019-5778: Insufficient policy enforcement in Extensions. Reported by David Erceg on 2019-01-02
[$500][904219] Low CVE-2019-5779: Insufficient policy enforcement in ServiceWorker. Reported by David Erceg on 2018-11-11
[$500][891697] Low CVE-2019-5780: Insufficient policy enforcement. Reported by Andreas Hegenberg (folivora.AI GmbH) on 2018-10-03
[$500][895081] Low CVE-2019-5783: Insufficient validation of untrusted input in DevTools. Reported by Shintaro Kobori on 2018-10-13

[$N/A][896725] Low CVE-2019-5781: Insufficient policy enforcement in Omnibox. Reported by evi1m0 of Bilibili Security Team on 2018-10-18

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:

  • [926238] 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,

Abdul Syed

by Abdul Syed (noreply@blogger.com) at February 08, 2019 10:53 AM

February 07, 2019

Google Chrome Releases

Stable Channel Update for Desktop

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


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 a security fix from an external researcher.
Please see the Chrome Security Page for more information.

[$3000][915975] Medium CVE-2019-5784: Inappropriate implementation in V8. Reported by Lucas Pinheiro, Microsoft Browser Vulnerability Research on 2018-12-18

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.

Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at February 07, 2019 01:46 PM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 72.0.3626.97 (Platform version: 11316.123.0, 11316.123.1) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bugInterested 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).

David McMahon
Google Chrome

by djmm (noreply@blogger.com) at February 07, 2019 01:25 PM

February 06, 2019

Google Chrome Releases

Chrome for Android Update

Good news, everyone!  Chrome 72 (72.0.3626.96) for Android has been released and will be available on Google Play over the course of the next few weeks. This release includes stability and performance improvements.

A list of the changes in this build is available in the Git log.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at February 06, 2019 04:31 PM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 73.0.3683.20 (Platform version: 11647.20.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found 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).

Cindy Bayless
Google Chrome

by Cindy Bayless (noreply@blogger.com) at February 06, 2019 08:43 AM

February 05, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 73.0.3683.20 for Windows, Mac & 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.
Srinivas Sista
Google Chrome

by Srinivas Sista (noreply@blogger.com) at February 05, 2019 09:37 AM

February 04, 2019

Google Chrome

Accessing the web on Chromebooks without a Wi-Fi access point

With Instant Tethering, you can access the internet on your Chromebook with your paired Android phone’s mobile data connection.

February 04, 2019 06:30 PM

February 01, 2019

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 72.0.3626.85 (Platform version: 11316.112.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bugInterested 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).

David McMahon
Google Chrome

by djmm (noreply@blogger.com) at February 01, 2019 01:53 PM

January 31, 2019

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 73.0.3683.10 for Windows, Mac & 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.
Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at January 31, 2019 12:51 PM

January 29, 2019

Igalia Chromium

Mario Sanchez Prada: Working on the Chromium Servicification Project

It’s been a few months already since I (re)joined Igalia as part of its Chromium team and I couldn’t be happier about it: right since the very first day, I felt perfectly integrated as part of the team that I’d be part of and quickly started making my way through the -fully upstream- project that would keep me busy during the following months: the Chromium Servicification Project.

But what is this “Chromium servicification project“? Well, according to the Wiktionary the word “servicification” means, applied to computing, “the migration from monolithic legacy applications to service-based components and solutions”, which is exactly what this project is about: as described in the Chromium servicification project’s website, the whole purpose behind this idea is “to migrate the code base to a more modular, service-oriented architecture”, in order to “produce reusable and decoupled components while also reducing duplication”.

Doing so would not only make Chromium a more manageable project from a source code-related point of view and create better and more stable interfaces to embed chromium from different projects, but should also enable teams to experiment with new features by combining these services in different ways, as well as to ship different products based in Chromium without having to bundle the whole world just to provide a particular set of features. 

For instance, as Camille Lamy put it in the talk delivered (slides here) during the latest Web Engines Hackfest,  “it might be interesting long term that the user only downloads the bits of the app they need so, for instance, if you have a very low-end phone, support for VR is probably not very useful for you”. This is of course not the current status of things yet (right now everything is bundled into a big executable), but it’s still a good way to visualise where this idea of moving to a services-oriented architecture should take us in the long run.

With this in mind, the idea behind this project would be to work on the migration of the different parts of Chromium depending on those components that are being converted into services, which would be part of a “foundation” base layer providing the core services that any application, framework or runtime build on top of chromium would need.

As you can imagine, the whole idea of refactoring such an enormous code base like Chromium’s is daunting and a lot of work, especially considering that currently ongoing efforts can’t simply be stopped just to perform this migration, and that is where our focus is currently aimed at: we integrate with different teams from the Chromium project working on the migration of those components into services, and we make sure that the clients of their old APIs move away from them and use the new services’ APIs instead, while keeping everything running normally in the meantime.

At the beginning, we started working on the migration to the Network Service (which allows to run Chromium’s network stack even without a browser) and managed to get it shipped in Chromium Beta by early October already, which was a pretty big deal as far as I understand. In my particular case, that stage was a very short ride since such migration was nearly done by the time I joined Igalia, but still something worth mentioning due to the impact it had in the project, for extra context.

After that, our team started working on the migration of the Identity service, where the main idea is to encapsulate the functionality of accessing the user’s identities right through this service, so that one day this logic can be run outside of the browser process. One interesting bit about this migration is that this particular functionality (largely implemented inside the sign-in component) has historically been located quite high up in the stack, and yet it’s now being pushed all the way down into that “foundation” base layer, as a core service. That’s probably one of the factors contributing to making this migration quite complicated, but everyone involved is being very dedicated and has been very helpful so far, so I’m confident we’ll get there in a reasonable time frame.

If you’re curious enough, though, you can check this status report for the Identity service, where you can see the evolution of this particular migration, along with the impact our team had since we started working on this part, back on early October. There are more reports and more information in the mailing list for the Identity service, so feel free to check it out and/or subscribe there if you like.

One clarification is needed, tough: for now, the scope of this migrations is focused on using the public C++ APIs that such services expose (see //services/<service_name>/public/cpp), but in the long run the idea is that those services will also provide Mojo interfaces. That will enable using their functionality regardless of whether you’re running those services as part of the browser’s process, or inside their own & separate processes, which will then allow the flexibility that chromium will need to run smoothly and safely in different kind of environments, from the least constrained ones to others with a less favourable set of resources at their disposal.

And this is it for now, I think. I was really looking forward to writing a status update about what I’ve been up to in the past months and here it is, even though it’s not the shortest of all reports.

One last thing, though: as usual, I’m going to FOSDEM this year as well, along with a bunch of colleagues & friends from Igalia, so please feel free to drop me/us a line if you want to chat and/or hangout, either to talk about work-related matters or anything else really.

And, of course, I’d be also more than happy to talk about any of the open job positions at Igalia, should you consider applying. There are quite a few of them available at the moment for all kind of things (most of them available for remote work): from more technical roles such as graphicscompilersmultimedia, JavaScript engines, browsers (WebKitChromium, Web Platform) or systems administration (this one not available for remotes, though), to other less “hands-on” types of roles like developer advocatesales engineer or project manager, so it’s possible there’s something interesting for you if you’re considering to join such an special company like this one.

See you in FOSDEM!

by mario at January 29, 2019 06:35 PM

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 72.0.3626.81 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.



Abdul Syed
Google Chrome

by Abdul Syed (noreply@blogger.com) at January 29, 2019 11:49 AM

Chrome for Android Update

Good news, everyone!  Chrome 72 (72.0.3626.76) for Android has been released and will be available on Google Play over the course of the next few weeks. This release includes stability and performance improvements.

A list of the changes in this build is available in the Git log.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at January 29, 2019 09:20 AM

January 28, 2019

Google Chrome Releases

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 72 (72.0.3626.76) for Android has been released and is available in Google Play.  A partial list of the changes in this build is available in the Git log. Details on new features is available on the Chromium blog, and developers should check out our updates related to the web platform here.

If you find a new issue, please let us know by filing a bug. More information about Chrome for Android is available on the Chrome site.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at January 28, 2019 03:57 PM

January 25, 2019

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 72.0.3626.74 (Platform version: 11316.98.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements.  A list of changes can be found here.

If you find new issues, please let us know by visiting our forum or filing a bugInterested 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).

David McMahon
Google Chrome

by djmm (noreply@blogger.com) at January 25, 2019 11:38 AM

Dev Channel Update for Chrome OS

The Dev channel has been updated to 73.0.3680.0 (Platform version: 11633.0.0) for most Chrome OS devices. This build contains a number of bug fixes, security updates and feature enhancements. A list of changes can be found 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).

Cindy Bayless
Google Chrome

by Cindy Bayless (noreply@blogger.com) at January 25, 2019 08:27 AM