Google today launched Chrome 48 for Windows, Mac, and Linux, adding custom notification buttons and removing RC4 encryption. You can update to the latest version now, using the browser’s built-in silent updater, or download it directly from google.com/chrome.

Chrome is arguably more than a browser: With over 1 billion users, it’s a major platform that web developers have to consider. In fact, with its regular additions and changes, developers have to keep up to ensure they are taking advantage of everything available.

Google has been toying with notifications in Chrome for years. Chrome apps and extensions have supported push notifications on desktop since May 2010 (first added in Chrome 5). More recently, webpages gained the ability to send push notifications to users with the release of Chrome 42, while the desktop notification center was removed in Chrome 47.

Chrome now delivers more than 350 million push notifications every day, according to Google. Chrome 48 takes this a step further by allowing sites to add custom buttons to notifications, so users can complete various tasks entirely within the notification.

chrome_48_custom_notification

Next up, the RC4 cipher is no longer supported over HTTPS connections. RC4 is a stream cipher, designed in 1987, that has been widely supported across browsers and online services for the purposes of encryption. Multiple vulnerabilities have been discovered in RC4 over the years, making it possible to crack within days, or even hours.

In February 2015, new attacks prompted the Internet Engineering Task Force (IETF) to prohibit the use of RC4 with TLS. Google, Microsoft, and Mozilla all promised to drop RC4 support in their respective browsers this year, and it just so happens that Chrome is first to deliver.

If you try to open a website that uses RC4 in Chrome 48, all you will get is the following error:

chrome_rc4_error

This change will undoubtedly push many outdated websites to beef up their security. In September 2015, Google shared that only 0.13 percent of HTTPS connections made by Chrome users who have opted into statistics collection currently use RC4.

Lastly, Chrome 48 now lets developers use NetworkInformation.downlinkMax to detect a device’s maximum bandwidth, or even the NetworkInformation.onChange event handler to respond to connection speed changes. With this information, they can then send the optimal resources for the given connection.

Other developer features in this release include:

Chrome 48 also includes 37 security fixes, of which Google chose to highlight the following:

  • [$3000][497632] High CVE-2016-1612: Bad cast in V8. Credit to cloudfuzzer.
  • [$3000][572871] High CVE-2016-1613: Use-after-free in PDFium. Credit to anonymous.
  • [$2000][544691] Medium CVE-2016-1614: Information leak in Blink. Credit to Christoph Diehl.
  • [$500][468179] Medium CVE-2016-1615: Origin confusion in Omnibox. Credit to Ron Masas.
  • [$500][541415] Medium CVE-2016-1616: URL Spoofing. Credit to Luan Herrera.
  • [$500][544765] Medium CVE-2016-1617: History sniffing with HSTS and CSP. Credit to jenuis.
  • [$500][552749] Medium CVE-2016-1618: Weak random number generator in Blink. Credit to Aaron Toponce.
  • [$500][557223] Medium CVE-2016-1619: Out-of-bounds read in PDFium. Credit to Keve Nagy.
  • [579625] CVE-2016-1620: Various fixes from internal audits, fuzzing and other initiatives.
  • Multiple vulnerabilities in V8 fixed at the tip of the 4.8 branch (currently 4.8.271.17).

If you add all those up, you’ll see Google spent just $10,500 in bug bounties, a paltry amount compared to the six figures it spent in Chrome 47. But that was a security-focused release, and as always, there are additional bounties that don’t yet have a reward amount set. The security fixes alone should be enough incentive for you to upgrade to Chrome 48.

Chrome 48 for Android and iOS are also on their way, but Google has not shared when they might ship. Chrome 48 for Android is a particularly interesting release. The new version is expected to let you send presentations to nearby Google Cast devices, meaning mobile sites will be able to present to external devices using the standards-based Presentation API and the Cast Web SDK.