The biggest addition in this release is 64-bit support for OS X, which first arrived in Chrome 38 beta. Unlike on Windows where 32-bit and 64-bit versions will both continue to be available (users currently have to opt-in to use the 64-bit release), Chrome for Mac is now only available in 64-bit.
All Chrome for Mac users on the stable channel will be updated to the 64-bit version when they get Chrome 39, which doesn’t have a 32-bit equivalent. While Google hasn’t explicitly said so, this would seem that first-generation Intel Macs will not be able to move past Chrome 38.
As Google has shared before, 64-bit support brings speed and security improvements to its browser:
64-bit Chrome has become faster as a result of having access to a superior instruction set, more registers, and a more efficient function calling convention. Improved opportunities for ASLR enhance this version’s security. Another major benefit of this change comes from the fact that most programs on a modern Mac are already 64-bit apps.
In cases where Chrome was the last remaining 32-bit app, there were launch-time and memory-footprint penalties as 32-bit copies of all of the system libraries needed to be loaded to support Chrome. Now that Chrome’s a 64-bit app too, we expect you’ll find that it launches more quickly and that overall system memory use decreases.
The move also means Chrome for Mac no longer supports 32-bit Netscape Plugin Application Programming Interface (NPAPI) plugins, although their 64-bit counterparts are supported. Google is hoping to drop 32-bit NPAPI plugin support from Chrome altogether, so this should come as no surprise, in order to “improve Chrome’s security, speed, and stability as well as reduce complexity in the code base.”
OS X aside, Chrome 39 brings a slew of new developer features. Here is what Google highlighted in the beta release:
- Web Animation Playback Control: Web Animations, a new API that shipped in Chrome 36 with basic support, now has playback control, including the methods play(), pause(), and reverse(), as well as the ability to jump to a specific point in an animation’s timeline.
- Web Application Manifests: Starting in Chrome 39, Manifests let developers wrap metadata about a Web application into a single file, reducing duplication and saving a bit of bandwidth. Adding apps to the homescreen is as easy as defining a title, landing page, default orientation, and multiple icons depending on size and screen density.
- The Beacon API lets developers queue asynchronous network requests that will be sent regardless of whether the user navigates to a new page.
- Scroll offsets (scrollTop, scrollLeft) now return high-precision fractional values in preparation for high-DPI support.
- XMLHttpRequest progress event properties position and totalSize are now deprecated in favor of the loaded and total properties.
Chrome 39 also includes 42 fixes (not as many as Chrome 38, but that was primarily a security release). Of these, Google chose to highlight the following:
- [$500] High CVE-2014-7899: Address bar spoofing. Credit to Eli Grey.
- [$1500] High CVE-2014-7900: Use-after-free in pdfium. Credit to Atte Kettunen from OUSPG.
- [$1000] High CVE-2014-7901: Integer overflow in pdfium. Credit to cloudfuzzer.
- [$1000] High CVE-2014-7902: Use-after-free in pdfium. Credit to cloudfuzzer.
- [$3000] High CVE-2014-7903: Buffer overflow in pdfium. Credit to cloudfuzzer.
- [$2000] High CVE-2014-7904: Buffer overflow in Skia. Credit to Atte Kettunen from OUSPG.
- [$2000] High CVE-2014-7905: Flaw allowing navigation to intents that do not have the BROWSABLE category. Credit to WangTao(neobyte) of Baidu X-Team.
- [$500] High CVE-2014-7906: Use-after-free in pepper plugins. Credit to Chen Zhang (demi6od) of the NSFOCUS Security Team.
- [$7500] High CVE-2014-0574: Double-free in Flash. Credit to biloulehibou.
- [$5000] High CVE-2014-7907: Use-after-free in blink. Credit to Chen Zhang (demi6od) of the NSFOCUS Security Team.
- [$500] High CVE-2014-7908: Integer overflow in media. Credit to Christoph Diehl.
- [$500] Medium CVE-2014-7909: Uninitialized memory read in Skia. Credit to miaubiz.
Google also rewarded Atte Kettunen, Christian Holler, cloudfuzzer, and mmaliszkiewicz with $16,500 for preventing security bugs from ever reaching the stable channel. If you add all those up, you’ll see Google spent a whopping $41,500 in bug bounties for this release.
The above list of security fixes should be enough to push Chrome users to upgrade as soon as possible.
Mobile developer or publisher? VentureBeat is studying mobile marketing automation. Fill out our 5-minute survey, and we’ll share the data with you.