Planet Chromium

October 17, 2018

Google Chrome Releases

Chrome for Android Update

Good news, everyone!  Chrome 70 (70.0.3538.64) 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.

Ben Mason
Google Chrome

by Ben Mason (noreply@blogger.com) at October 17, 2018 04:51 PM

Dev Channel Update for Desktop

The dev channel has been updated to 71.0.3578.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.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at October 17, 2018 11:44 AM

Google Chrome

Schools in London give new life to old computers

Schools can bring life to old, ageing devices by replacing existing operating systems with one that is easy to manage and ready for the cloud.

October 17, 2018 08:00 AM

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 71.0.3578.8 (Platform version: 11151.4.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).

Kevin Bleicher
Google Chrome

by Kevin Bleicher (noreply@blogger.com) at October 17, 2018 08:23 AM

October 16, 2018

Google Chrome Releases

Stable Channel Update for Desktop

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

Chrome 70.0.3538.67 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 70.


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

[$N/A][888926] High CVE-2018-17462: Sandbox escape in AppCache. Reported by Ned Williamson and Niklas Baumstark working with Beyond Security’s SecuriTeam Secure Disclosure program on 2018-09-25
[$N/A][888923] High CVE-2018-17463: Remote code execution in V8. Reported by Samuel Gross working with Beyond Security’s SecuriTeam Secure Disclosure program on 2018-09-25
[$3500][872189] High CVE to be assigned: Heap buffer overflow in Little CMS in PDFium. Reported by Quang Nguyễn (@quangnh89) of Viettel Cyber Security on 2018-08-08
[$3000][887273] High CVE-2018-17464: URL spoof in Omnibox. Reported by xisigr of Tencent's Xuanwu Lab on 2018-09-20
[$3000][870226] High CVE-2018-17465: Use after free in V8. Reported by Lin Zuojian on 2018-08-02
[$1000][880906] High CVE-2018-17466: Memory corruption in Angle. Reported by Omair on 2018-09-05
[$3000][844881] Medium CVE-2018-17467: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-05-19
[$2000][876822] Medium CVE-2018-17468: Cross-origin URL disclosure in Blink. Reported by James Lee (@Windowsrcer) of Kryptos Logic on 2018-08-22
[$1000][880675] Medium CVE-2018-17469: Heap buffer overflow in PDFium. Reported by Zhen Zhou of NSFOCUS Security Team on 2018-09-05
[$1000][877874] Medium CVE-2018-17470: Memory corruption in GPU Internals. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2018-08-27
[$1000][873080] Medium CVE-2018-17471: Security UI occlusion in full screen mode. Reported by Lnyas Zhang on 2018-08-10
[$1000][822518] Medium CVE-2018-17472: iframe sandbox escape on iOS. Reported by Jun Kokatsu (@shhnjk) on 2018-03-16
[$500][882078] Medium CVE-2018-17473: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-09-08
[$500][843151] Medium CVE-2018-17474: Use after free in Blink. Reported by Zhe Jin(金哲),Luyao Liu(刘路遥) from Chengdu Security Response Center of Qihoo 360 Technology Co. Ltd on 2018-05-15
[$500][852634] Low CVE-2018-17475: URL spoof in Omnibox. Reported by Vladimir Metnew on 2018-06-14
[$500][812769] Low CVE-2018-17476: Security UI occlusion in full screen mode. Reported by Khalil Zhani on 2018-02-15
[$500][805496] Low CVE-2018-5179: Lack of limits on update() in ServiceWorker. Reported by Yannic Bonenberger on 2018-01-24
[$N/A][863703] Low CVE-2018-17477: UI spoof in Extensions. Reported by Aaron Muir Hamilton <aaron@correspondwith.me> on 2018-07-14

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:
  • [895893] 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 October 16, 2018 09:53 PM

Google Chrome

When Octoberitis spooks your students, we’re here to help

Get your classroom re-inspired this October with new tips, tools, and treats (but no tricks!) from Google for Education.

October 16, 2018 04:00 PM

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 70.0.3538.67 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 October 16, 2018 01:01 PM

October 15, 2018

Google Chrome Releases

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 70 (70.0.3538.64) 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 October 15, 2018 05:27 PM

October 12, 2018

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 70.0.3538.58 (Platform version: 11021.45.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).

Geo  Hsu
Google Chrome

by Geo Hsu (noreply@blogger.com) at October 12, 2018 10:49 AM

October 11, 2018

Igalia Chromium

Andy Wingo: heap object representation in spidermonkey

I was having a look through SpiderMonkey's source code today and found something interesting about how it represents heap objects and wanted to share.

I was first looking to see how to implement arbitrary-length integers ("bigints") by storing the digits inline in the allocated object. (I'll use the term "object" here, but from JS's perspective, bigints are rather values; they don't have identity. But I digress.) So you have a header indicating how many words it takes to store the digits, and the digits follow. This is how JavaScriptCore and V8 implementations of bigints work.

Incidentally, JSC's implementation was taken from V8. V8's was taken from Dart. Dart's was taken from Go. We might take SpiderMonkey's from Scheme48. Good times, right??

When seeing if SpiderMonkey could use this same strategy, I couldn't find how to make a variable-sized GC-managed allocation. It turns out that in SpiderMonkey you can't do that! SM's memory management system wants to work in terms of fixed-sized "cells". Even for objects that store properties inline in named slots, that's implemented in terms of standard cell sizes. So if an object has 6 slots, it might be implemented as instances of cells that hold 8 slots.

Truly variable-sized allocations seem to be managed off-heap, via malloc or other allocators. I am not quite sure how this works for GC-traced allocations like arrays, but let's assume that somehow it does.

Anyway, the point of this blog post. I was looking to see which part of SpiderMonkey reserves space for type information. For example, almost all objects in V8 start with a "map" word. This is the object's "hidden class". To know what kind of object you've got, you look at the map word. That word points to information corresponding to a class of objects; it's not available to store information that might vary between objects of that same class.

Interestingly, SpiderMonkey doesn't have a map word! Or at least, it doesn't have them on all allocations. Concretely, BigInt values don't need to reserve space for a map word. I can start storing data right from the beginning of the object.

But how can this work, you ask? How does the engine know what the type of some arbitrary object is?

The answer has a few interesting wrinkles. Firstly I should say that for objects that need hidden classes -- e.g. generic JavaScript objects -- there is indeed a map word. SpiderMonkey calls it a "Shape" instead of a "map" or a "hidden class" or a "structure" (as in JSC), but it's there, for that subset of objects.

But not all heap objects need to have these words. Strings, for example, are values rather than objects, and in SpiderMonkey they just have a small type code rather than a map word. But you know it's a string rather than something else in two ways: one, for "newborn" objects (those in the nursery), the GC reserves a bit to indicate whether the object is a string or not. (Really: it's specific to strings.)

For objects promoted out to the heap ("tenured" objects), objects of similar kinds are allocated in the same memory region (in kind-specific "arenas"). There are about a dozen trace kinds, corresponding to arena kinds. To get the kind of object, you find its arena by rounding the object's address down to the arena size, then look at the arena to see what kind of objects it has.

There's another cell bit reserved to indicate that an object has been moved, and that the rest of the bits have been overwritten with a forwarding pointer. These two reserved bits mostly don't conflict with any use a derived class might want to make from the first word of an object; if the derived class uses the first word for integer data, it's easy to just reserve the bits. If the first word is a pointer, then it's probably always aligned to a 4- or 8-byte boundary, so the low bits are zero anyway.

The upshot is that while we won't be able to allocate digits inline to BigInt objects in SpiderMonkey in the general case, we won't have a per-object map word overhead; and we can optimize the common case of digits requiring only a word or two of storage to have the digit pointer point to inline storage. GC is about compromise, and it seems this can be a good one.

Well, that's all I wanted to say. Looking forward to getting BigInt turned on upstream in Firefox!

by Andy Wingo at October 11, 2018 02:33 PM

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 71.0.3572.0 (Platform version: 11143.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).

David McMahon
Google Chromecheapairfare

by djmm (noreply@blogger.com) at October 11, 2018 09:42 AM

October 10, 2018

Google Chrome Releases

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 70 (70.0.3538.57) 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 October 10, 2018 09:18 PM

Beta Channel Update for Desktop

The beta channel has been updated to 70.0.3538.54 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 October 10, 2018 03:43 PM

Stable Channel Update for Chrome OS

The Stable channel has been updated to 69.0.3497.120 (Platform version: 10895.78.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).

Bernie Thompson
Google Chrome

by Cindy Bayless (noreply@blogger.com) at October 10, 2018 10:47 AM

October 09, 2018

Igalia Chromium

Manuel Rego: Web Engines Hackfest 2018

One year more and a new edition of the Web Engines Hackfest was arranged by Igalia. This time it was the tenth edition, the first five ones using the WebKitGTK+ Hackfest name and another five editions with the new broader name Web Engines Hackfest. A group of igalians, including myself, have been organizing this event. It has been some busy days for us, but we hope everyone enjoyed it and had a great time during the hackfest.

This was the biggest edition ever, we were 70 people from 15 different companies including Apple, Google and Mozilla (three of the main browser vendors). It seems the hackfest is getting more popular, several people attending are repeating in the next editions, so that shows they enjoy it. This is really awesome and we’re thrilled about the future of this event.

Talks

The presentations are not the main part of the event, but I think it’s worth to do a quick recap about the ones we had this year:

  • Behdad Esfahbod and Dominik Röttsches from Google talked about Variable Fonts and the implementation in Chromium. It’s always amazing to check the possibilities of this new technology.

  • Camille Lamy, Colin Blundell and Robert Kroeger from Google presented the Servicification effort in the Chromium project. Which is trying to modularize Chromium in smaller parts.

  • Žan Doberšek from Igalia gave an update on WPE WebKit. The port is now official and it’s used everyday in more and more low-end devices.

  • Thibault Saunier from Igalia complemented Žan’s presentation talking about the GStreamer based WebRTC implementation in WebKitGTK+ and WPE ports. Really cool to see WebRTC arriving to more browsers and web engines.

  • Antonio Gomes and Jeongeun Kim from Igalia explained the status of Chromium on Wayland and it’s way to become fully supported upstream. This work will help to use Chromium on embedded systems.

  • Youenn Fablet from Apple closed the event talking about Service Workers support on WebKit. This is a key technology for Progressive Web Apps (PWA) and is now available in all major browsers.

The slides of the talks are available on the website and wiki. The videos will be published soon in our YouTube channel.

Some pictures from Web Engines Hackfest 2018 Some pictures from Web Engines Hackfest 2018 (Flickr album)

Other topics

During the event there were breakout sessions about many different topics. In this section I’m going to talk about the ones I’m more interested on.

  • Web Platform Tests (WPT)

    This is a key topic to improve interoperability on the web platform. Simon Pieters started the session with an introduction to WPT just in case someone was not aware of the repository and how it works. For the rest of the session we discussed the status of WPT on the different browsers.

    Chromium and Firefox are doing an automatic two ways (import/export) synchronization process so the tests can be easily shared between both implementations. On the other side WebKit still has some kind of manual process over the table, neither import or export is totally automatic, there are some scripts that help with the process though.

    Apart from that, WPT is a first-class citizen in Chromium, and the encouraged way to do new developments. In Firefox it’s still not there, as the test suites are not run in all the possible configurations yet (but they’re getting there).

    Finally the WPT dashboard is showing results for the most recent unstable releases of the different browsers, which is really cool despite being somehow hidden on the UI: https://wpt.fyi/results/?label=experimental.

  • LayoutNG

    Christian Biesinger gave an introduction to LayoutNG project in Blink, where Google is rewriting Chromium’s layout engine. He showed the main ideas and concepts behind this effort and navigated the code showing some examples. According to Christian things are getting ready and LayoutNG could be shipping in the coming months for inline and block layout.

    On top of questions about LayoutNG, we briefly mentioned how other browsers are also trying to improve the layout code: Firefox with Servo layout and WebKit with Layout Formatting Context (LFC) aka Layout Reloaded. It seems quite clear that the current layout engines are getting to their limits and people are looking for new solutions.

  • Chromium downstream

    Several companies (Google included) have to maintain downstream forks Chromium with their own customizations to fit their particular use cases and hardware platforms.

    Colin Blundell was explaining how it was the process of maintaining the downstream version of Chrome for iOS. After trying many different strategies the best solution was rebasing their changes 2-3 times per day. That way the conflicts they had to deal with were much simpler to resolve, otherwise it was not possible for them to cope with all the upstream changes. Note that he mentioned that one (rotatory) full-time resource was required to perform this job in time.

    It was good to share the experiences of different companies that are facing very similar issues for this kind of work.

Thank you very much

Just to close this post, big thanks to all the people attending the event, without you the hackfest wouldn’t have any sense at all. People are key for this event where discussions and conversations are one of the main parts of it.

Of course special acknowledgments to the speakers for the hard work they put on their lovely talks.

Finally I couldn’t forget to thank the Web Engines Hackfest 2018 sponsors: Google and Igalia. Without their support this event won’t be possible.

Web Engines Hackfest 2018 sponsors: Google and Igalia Web Engines Hackfest 2018 sponsors: Google and Igalia

Looking forward for a new edition!

October 09, 2018 10:00 PM

Google Chrome Releases

Dev Channel Update for Desktop

The dev channel has been updated to 71.0.3573.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.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at October 09, 2018 12:27 PM

October 04, 2018

Google Chrome Releases

Dev Channel Update for Chrome OS

The Dev channel has been updated to 71.0.3567.0 (Platform version: 11125.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).

Kevin Bleicher
Google Chrome

by Kevin Bleicher (noreply@blogger.com) at October 04, 2018 04:13 PM

Dev Channel Update for Desktop

The dev channel has been updated to 71.0.3569.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.

Krishna Govind
Google Chrome

by Krishna Govind (noreply@blogger.com) at October 04, 2018 12:19 PM

Chrome Beta for Android Update

Ladies and gentlemen, behold!  Chrome Beta 70 (70.0.3538.46) 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 October 04, 2018 08:03 AM

October 03, 2018

Google Chrome Releases

Beta Channel Update for Desktop

The beta channel has been updated to 70.0.3538.45 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 October 03, 2018 12:40 PM

October 01, 2018

Chromium Blog

Trustworthy Chrome Extensions, by default

li { line-height: 1.38 !important; }
Incredibly, it’s been nearly a decade since we launched the Chrome extensions system. Thanks to the hard work and innovation of our developer community, there are now more than 180,000 extensions in the Chrome Web Store, and nearly half of Chrome desktop users actively use extensions to customize Chrome and their experience on the web.


The extensions team's dual mission is to help users tailor Chrome’s functionality to their individual needs and interests, and to empower developers to build rich and useful extensions. But, first and foremost, it’s crucial that users be able to trust the extensions they install are safe, privacy-preserving, and performant. Users should always have full transparency about the scope of their extensions’ capabilities and data access.


We’ve recently taken a number of steps toward improved extension security with the launch of out-of-process iframes, the removal of inline installation, and significant advancements in our ability to detect and block malicious extensions using machine learning. Looking ahead, there are more fundamental changes needed so that all Chrome extensions are trustworthy by default.


Today we’re announcing some upcoming changes and plans for the future:


User controls for host permissions
Beginning in Chrome 70, users will have the choice to restrict extension host access to a custom list of sites, or to configure extensions to require a click to gain access to the current page.




While host permissions have enabled thousands of powerful and creative extension use cases, they have also led to a broad range of misuse - both malicious and unintentional - because they allow extensions to automatically read and change data on websites. Our aim is to improve user transparency and control over when extensions are able to access site data. In subsequent milestones, we’ll continue to optimize the user experience toward this goal while improving usability. If your extension requests host permissions, we encourage you to review our transition guide and begin testing as soon as possible.



Changes to the extensions review process
Going forward, extensions that request powerful permissions will be subject to additional compliance review. We’re also looking very closely at extensions that use remotely hosted code, with ongoing monitoring. Your extension’s permissions should be as narrowly-scoped as possible, and all your code should be included directly in the extension package, to minimize review time.



New code readability requirements
Starting today, Chrome Web Store will no longer allow extensions with obfuscated code. This includes code within the extension package as well as any external code or resource fetched from the web. This policy applies immediately to all new extension submissions. Existing extensions with obfuscated code can continue to submit updates over the next 90 days, but will be removed from the Chrome Web Store in early January if not compliant.


Today over 70% of malicious and policy violating extensions that we block from Chrome Web Store contain obfuscated code. At the same time, because obfuscation is mainly used to conceal code functionality, it adds a great deal of complexity to our review process. This is no longer acceptable given the aforementioned review process changes.


Additionally, since JavaScript code is always running locally on the user's machine, obfuscation is insufficient to protect proprietary code from a truly motivated reverse engineer. Obfuscation techniques also come with hefty performance costs such as slower execution and increased file and memory footprints.


Ordinary minification, on the other hand, typically speeds up code execution as it reduces code size, and is much more straightforward to review. Thus, minification will still be allowed, including the following techniques:

  • Removal of whitespace, newlines, code comments, and block delimiters
  • Shortening of variable and function names
  • Collapsing the number of JavaScript files


If you have an extension in the store with obfuscated code, please review our updated content policies as well as our recommended minification techniques for Google Developers, and submit a new compliant version before January 1st, 2019.


Required 2-Step Verification
In 2019, enrollment in 2-Step Verification will be required for Chrome Web Store developer accounts. If your extension becomes popular, it can attract attackers who want to steal it by hijacking your account, and 2-Step Verification adds an extra layer of security by requiring a second authentication step from your phone or a physical security key. We strongly recommend that you enroll as soon as possible.

For even stronger account security, consider the Advanced Protection Program. Advanced protection offers the same level of security that Google relies on for its own employees, requiring a physical security key to provide the strongest defense against phishing attacks.



Looking ahead: Manifest v3
In 2019 we will introduce the next extensions manifest version. Manifest v3 will entail additional platform changes that aim to create stronger security, privacy, and performance guarantees. We want to help all developers fall into the pit of success; writing a secure and performant extension in Manifest v3 should be easy, while writing an insecure or non-performant extension should be difficult.


Some key goals of manifest v3 include:
  • More narrowly-scoped and declarative APIs, to decrease the need for overly-broad access and enable more performant implementation by the browser, while preserving important functionality
  • Additional, easier mechanisms for users to control the permissions granted to extensions
  • Modernizing to align with new web capabilities, such as supporting Service Workers as a new type of background process

We intend to make the transition to manifest v3 as smooth as possible and we’re thinking carefully about the rollout plan. We’ll be in touch soon with more specific details.


We recognize that some of the changes announced today may require effort in the future, depending on your extension. But we believe the collective result will be worth that effort for all users, developers, and for the long term health of the Chrome extensions ecosystem. We’re committed to working with you to transition through these changes and are very interested in your feedback. If you have questions or comments, please get in touch with us on the Chromium extensions forum.


Posted by James Wagner, Chrome Extensions Product Manager



by Chrome Blog (noreply@blogger.com) at October 01, 2018 11:07 AM

September 27, 2018

Google Chrome Releases

Beta Channel Update for Chrome OS

The Beta channel has been updated to 70.0.3538.34 (Platform version: 11021.28.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).

Geo  Hsu
Google Chrome

by Geo Hsu (noreply@blogger.com) at September 27, 2018 09:40 AM

Beta Channel Update for Chrome OS

The Beta channel has been updated to 70.0.3538.22 (Platform version: 11021.19.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).

Geo  Hsu
Google Chrome

by Geo Hsu (noreply@blogger.com) at September 27, 2018 09:33 AM