[go: up one dir, main page]

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.
Credential Management API
Many sites allow their users to sign in to receive personalized content. Today that requires remembering and typing credentials, which lowers account security when users reuse passwords across multiple sites. Modern browsers have credential managers that remember and autofill saved passwords, but these managers cannot account for custom login flows or remember federated identity preferences.


The latest version of Chrome now supports the Credential Management API, allowing sites to interact with the browser’s credential manager to improve the login experience for users. The API enables users to sign in with one tap and lets them automatically sign back in when returning to the site.

Screen Shot 2016-04-28 at 13.56.55.png
Signing in with one tap using the Credential Management API


Reducing the overhead of offscreen rendering

Modern websites commonly embed cross-origin content like videos, social widgets, and ads. Embedding these resources allows sites to offer compelling content experiences, but it also creates a lot of overhead that can jank the page in ways the embedding site can’t control. The latest version of Chrome no longer runs the rendering pipeline or requestAnimationFrame() callbacks for cross-origin frames that are offscreen. This eliminates unnecessary work and reduces power consumption by up to 30% on several popular mobile sites without affecting the user experience.
Additional features in this release
Other changes
  • The ability to customize the message shown in the onbeforeunload dialog has been removed to protect users from malicious websites and align with other browsers.
  • Chrome on Android now uses the same media pipeline as desktop Chrome, improving  WebAudio support and allowing sites to interact with the playback rate on <audio> and <video> tags.
  • The latest version of Chrome improves web animations interoperability by supporting lists of values and removing dashed-names in keyframes.
  • Chrome now requires a border style to paint border images, improving spec compliance and interoperability.
  • Percentages can now be used for the sizes of flex item children.
  • DHE-based ciphers have been deprecated and will be removed in Chrome 52 in favor of ECDHE ciphers to improve TLS security.

Posted by Sabine Borsay and Mike West, Authenticator's Apprentices


Updated 7/12/2016: High submission volume has led to review latency that is longer than normal, so we've extended the grace period. The new policy will be enforced beginning September 6th, 2016
Today we’re updating the User Data Policy for the Chrome Web Store. Principles of transparency and choice over how users’ personal data is handled have long been key parts of Google’s philosophy. Since early on, Chrome has included privacy-protecting features to give users control over their browsing experience, including incognito mode and granular privacy preferences. Now, we’re consolidating and expanding our policies about user data to ensure our Chrome Web Store developers follow similar principles.


Chrome provides robust APIs that empower developers to create compelling extensions and apps, and users often need to provide access to their data to allow these services to run. The new User Data Policy extends existing policies to ensure transparent use of the data in a way that is consistent with the wishes and expectations of users. Some of the new requirements for developers are:


  • Be transparent about the handling of user data and disclose privacy practices
  • Post a privacy policy and use encryption, when handling personal or sensitive information, and
  • Ask users to consent to the collection of personal or sensitive data via a prominent disclosure, when the use of the data isn’t related to a prominent feature.


The policy also has other requirements, including prohibiting the collection of web browsing activity when it’s not required for an item’s main functionality. The full text of the policy is available in our Developer Program Policies and more information is available in the FAQ section.


We'll notify developers when we discover items that violate the User Data Policy, and they'll have until July 14, 2016 to make any changes needed for compliance. Starting July 15th, 2016, items that violate the policy will be removed from the Web Store and will need to become compliant to be reinstated.


Protecting our users is our key priority, and we believe this change will make sure users are better informed and allow them to choose how their user data is handled.


Posted by Teresita Perez and Athas Nikolakakos, Chrome Policy Team

The app launcher makes Chrome apps easy to open outside the browser, but we’ve found that users on Windows, Mac, and Linux prefer to launch their apps from within Chrome. With Chrome’s continued emphasis on simplicity and streamlining browser features, the launcher will be removed from those platforms. It will remain unchanged on Chrome OS.


The removal process will take place over the next several months. Beginning in a few weeks, Chrome will no longer enable the launcher when users first install a Chrome app. Anyone who currently has the launcher will receive a notice informing them that the launcher will be going away. In July, existing instances of the launcher will be removed. 


Chrome apps can still be accessed by clicking the apps shortcut in the bookmarks bar or typing chrome://apps in the omnibox. Learn more about opening Chrome apps by visiting the help center.


Posted by Marc Pawliger, Engineering Director

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.


Push notification improvements
Push notifications allow a site to trigger system-level notifications in the same way that native applications do. The initial version of push notifications relied on service workers to proactively fetch the information for a notification from the server. This led to problems when there were multiple messages in flight or when the device was on a flaky network connection. The latest version of Chrome allows sites to include notification data payloads with their push messages to eliminate the final server check. To protect user privacy, push notification payloads must be encrypted. Push notification payloads are part of the Push API spec and already supported in Firefox.

In addition to payloads, sites can now detect when a notification is closed by the user, enabling better analytics and allowing cross-device notification dismissal. Sites can also control the look of notifications more finely, setting custom timestamps and icons for notification actions. When updating a notification, sites can specify whether the device should alert the user with sound or vibration, or remain silent.


In Chrome 50, notification actions support custom icons.

Declarative preload
Sometimes there are resources needed to fully display a page that Chrome doesn’t know about until other resources are loaded. For example, a large JavaScript file may require a particular stylesheet, but Chrome doesn’t know to load the CSS until the JavaScript has run. Chrome now supports the <link rel='preload'> attribute, allowing developers to specify resources that should be downloaded preemptively and reducing the time to get meaningful content in front of users.

Chrome 50 (left) loading a page with preload vs. Chrome 49 (right) loading the page without.
Other features in this release

Minor changes

  • Chrome now supports the X25519 curve for TLS, allowing faster, simpler encryption.
  • -webkit-background-composite has been removed since it was nonstandard and had low usage.
  • The SVGZoomEvent, which was a no-op in Chrome, has been deprecated to improve spec compliance.
  • The RTCPeerConnection methods createOffer() and createAnswer() have been deprecated to enable promise-based implementations.
  • <link rel='subresource'> has been deprecated in favor of <link rel='preload'>, as described above.
  • XMLHTTPRequestProgressEvent has been removed in favor of ProgressEvent to improve spec compliance.
  • The Document.defaultCharset attribute has been removed to improve spec compliance.
  • KeyboardEvent.prototype.keyLocation has been removed in favor of KeyboardEvent.prototype.location, which is supported across more browsers.
  • The SVGElement.offset* methods have been removed from all elements except HTMLElement to improve spec compliance.



Posted by Peter Beverloo and Nicolás Satragno, Notification Knights