Chrome 68 arrives with new APIs and all HTTP sites marked as not secure

Google today launched Chrome 68 for Windows, Mac, and Linux. The release includes the Page Lifecycle API, the Payment Handler API, and a change to how the browser labels HTTP sites: They are all now marked as “Not secure” right in the address bar. You can update to the latest version now using Chrome’s built-in updater or download it directly from google.com/chrome.

With over 1 billion users, Chrome is both a browser and a major platform that web developers must consider. In fact, with Chrome’s regular additions and changes, developers often make a point to ensure they are aware of everything available — as well as what has been deprecated or removed.

HTTPS is a more secure version of the HTTP protocol used on the internet to connect users to websites. Secure connections are widely considered a necessary measure to decrease the risk of users being vulnerable to content injection (which can result in eavesdropping, man-in-the-middle attacks, and other data modification). Data is kept secure from third parties, and users can be more confident they are communicating with the correct website.

Google has been pushing the web to HTTPS for years, but it accelerated its efforts last year by making changes to Chrome’s user interface. Chrome 56, released in January 2017, started marking HTTP pages that collect passwords or credit cards as “Not secure.” Chrome 62, released in October 2017, started marking HTTP sites with entered data and all HTTP sites viewed in Incognito mode as “Not secure.”

As a result, over 85 percent of Chrome traffic on both Chrome OS and Mac are now HTTPS, while 76 percent of Chrome traffic on Android and Windows is also HTTPS. But Google isn’t satisfied with those numbers (you can view the latest progress for yourself here).

With Chrome 68, here is how HTTP sites now appear in the address bar:

Here is how Google explains its thinking behind the change:

Chrome’s new interface will help users understand that all HTTP sites are not secure, and continue to move the web towards a secure HTTPS web by default. HTTPS is easier and cheaper than ever before, and it unlocks both performance improvements and powerful new features that are too sensitive for HTTP.

Google isn’t stopping there. With the release of Chrome 69 in September, HTTPS sites will no longer sport the “Secure” wording:

With the release of Chrome 70 in October, HTTP sites will show a red “Not secure” warning when users enter data:

The plan was always to mark all HTTP sites as “Not secure.” Eventually, Google will change the icon beside the “Not secure” label and make the text red to further emphasize you should not trust HTTP sites:

This isn’t the only security improvement that Chrome 68 brings. Content embedded in an iframe now requires a user gesture to navigate the top-level browsing context to a different origin. Similar to pop-up blocking, Chrome will prompt users with an option to allow the redirect the continue. Previously, content embedded in an iframe could navigate the top-level browsing context to a different website (unless forbidden by the sandbox attribute). This functionality is used by many types of websites, including single-sign-on providers, payment processors, and of course those that redirected users to unwanted destinations without their knowledge or consent.

Similarly, Chrome will now also prevent tab-unders — when a page both opens a popup to some destination and navigates the opener page to some third-party content. These unwanted navigations will instead result in Chrome notifying the user so they can choose whether to follow this redirect or not.

Chrome 68 also implements 42 security fixes. The following ones were found by external researchers:

• [$5000][850350] High CVE-2018-6153: Stack buffer overflow in Skia. Reported by Zhen Zhou of NSFOCUS Security Team on 2018-06-07
• [$3000][848914] High CVE-2018-6154: Heap buffer overflow in WebGL. Reported by Omair on 2018-06-01
• [$N/A][842265] High CVE-2018-6155: Use after free in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2018-05-11
• [$N/A][841962] High CVE-2018-6156: Heap buffer overflow in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2018-05-10
• [$N/A][840536] High CVE-2018-6157: Type confusion in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2018-05-07
• [$2000][841280] Medium CVE-2018-6158: 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-09
• [$2000][837275] Medium CVE-2018-6159: Same origin policy bypass in ServiceWorker. Reported by Jun Kokatsu (@shhnjk) on 2018-04-26
• [$1000][839822] Medium CVE-2018-6160: URL spoof in Chrome on iOS. Reported by evi1m0 of Bilibili Security Team on 2018-05-04
• [$1000][826552] Medium CVE-2018-6161: Same origin policy bypass in WebAudio. Reported by Jun Kokatsu (@shhnjk) on 2018-03-27
• [$1000][804123] Medium CVE-2018-6162: Heap buffer overflow in WebGL. Reported by Omair on 2018-01-21
• [$500][849398] Medium CVE-2018-6163: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-06-04
• [$500][848786] Medium CVE-2018-6164: Same origin policy bypass in ServiceWorker. Reported by Jun Kokatsu (@shhnjk) on 2018-06-01
• [$500][847718] Medium CVE-2018-6165: URL spoof in Omnibox. Reported by evi1m0 of Bilibili Security Team on 2018-05-30
• [$500][835554] Medium CVE-2018-6166: URL spoof in Omnibox. Reported by Lnyas Zhang on 2018-04-21
• [$500][833143] Medium CVE-2018-6167: URL spoof in Omnibox. Reported by Lnyas Zhang on 2018-04-15
• [$500][828265] Medium CVE-2018-6168: CORS bypass in Blink. Reported by Gunes Acar and Danny Y. Huang of Princeton University, Frank Li of UC Berkeley on 2018-04-03
• [$500][394518] Medium CVE-2018-6169: Permissions bypass in extension installation . Reported by Sam P on 2014-07-16
• [$TBD][862059] Medium CVE-2018-6170: Type confusion in PDFium. Reported by Anonymous on 2018-07-10
• [$TBD][851799] Medium CVE-2018-6171: Use after free in WebBluetooth. Reported by amazon@mimetics.ca on 2018-06-12
• [$TBD][847242] Medium CVE-2018-6172: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-05-28
• [$TBD][836885] Medium CVE-2018-6173: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-04-25
• [$N/A][835299] Medium CVE-2018-6174: Integer overflow in SwiftShader. Reported by Mark Brand of Google Project Zero on 2018-04-20
• [$TBD][826019] Medium CVE-2018-6175: URL spoof in Omnibox. Reported by Khalil Zhani on 2018-03-26
• [$N/A][666824] Medium CVE-2018-6176: Local user privilege escalation in Extensions. Reported by Jann Horn of Google Project Zero on 2016-11-18
• [$500][826187] Low CVE-2018-6177: Cross origin information leak in Blink. Reported by Ron Masas (Imperva) on 2018-03-27
• [$500][823194] Low CVE-2018-6178: UI spoof in Extensions. Reported by Khalil Zhani on 2018-03-19
• [$500][816685] Low CVE-2018-6179: Local file information leak in Extensions. Reported by Anonymous on 2018-02-26
• [$500][797461] Low CVE-2018-6044: Request privilege escalation in Extensions . Reported by Rob Wu on 2017-12-23
• [$500][791324] Low CVE-2018-4117: Cross origin information leak in Blink. Reported by AhsanEjaz – @AhsanEjazA on 2017-12-03

Google thus spent at least $21,000 in bug bounties for this release. As always, the security fixes alone should be enough incentive for you to upgrade.

Security aside, Chrome 68 lets developers listen for, and respond to, system-initiated CPU suspension of backgrounded tabs using the new freeze and resume events in the Page Lifecycle API. When a frozen page needs to be discarded to conserve memory, the document.wasDiscarded property lets developers restore view state (saved in the freeze event) when the user refocuses the tab and the page is reloaded. You can test these events by visiting chrome://discards to simulate page freezing, resuming, and discarding.

The Payment Handler API builds on the Payment Request API, which helped users check out online. The new API enables web-based payment apps to facilitate payments directly within the Payment Request experience, as seen above.

As with every version, Chrome 68 includes an update to the V8 JavaScript engine: version 6.8. It reduces memory consumption as well as includes improvements to array destructuring, Object.assign, and TypedArray.prototype.sort. Check out the full list of changes for more information.

Other developer features in this release (some are mobile-specific) include:

• Accept two values in the overflow shorthand: The overflow shorthand will accept two values, making it possible to set the horizontal and vertical overflow to different values. If two values are specified, the first is overflow-x and the second is overflow-y. Changing the shorthand allows developers to specify a single statement where previously two were required.
• CSS position values with three parts: The object-position and perspective-origin properties will no longer accept three-part values like "top right 20%". This also applies for positions in basic shapes and gradients. Valid position values will now always have 1, 2 or 4 parts. Deprecation of 3-part values occurred in Chrome 66.
• Support ‘x’ as a resolution unit: CSS Values and Units Module Level 4 defines a new resolution unit called “dot per pixel” for support of high-resolution displays. This change adds 'x' as a synonym for the existing abbreviation, 'dppx'.
• Unprefix CSS “grab” and “grabbing” values for cursor property: The CSS values “grab” and “grabbing” change the mouse cursor to an open hand or closed hand, commonly used to indicate that something can be grabbed or is currently grabbed. Prefixed versions of these properties have been supported since Chrome 1. With this change Chrome will support the standard, unprefixed versions of these values.
• High resolution timestamp for Gamepad: Gamepad.timestamp now uses a DOMHighResTimeStamp, a high resolution monotonic time with microsecond resolution. Timestamps are measured as offsets from the PerformanceTiming.navigationStart property.
• New customElements.upgrade(): This function invokes custom element constructors for custom elements whose constructors are not called yet explicitly. If a custom element is created with the innerHTML setter and its parent node is not connected to a document, the custom element constructor is not called until it’s connected. This method explicitly allows developers to fully control the timing of custom element constructor calls regardless of connectedness.
• Keyboard lock: While in fullscreen, this API allows apps to receive keys that are normally handled by the system or the browser like Cmd-Tab/Alt-Tab, or Esc. Users can escape keyboard lock (and fullscreen) by holding the Esc key for two seconds.
• Make PointerEvent.fromElement and PointerEvent.toElement null: To improve consistency with other browsers, PointerEvents for fromElement and toElement fields not follow the Pointer Events Level 2 spec by always reporting null. In a MouseEvent (from which a PointerEvent inherits these fields), fromElement and toElement are non-standard, and have been inconsistent among major browsers for many years. Moreover, there are standard and consistent alternatives already: target and relatedTarget.
• Unified touch adjustment: Touch adjustment changes the TouchEvent and the corresponding PointerEvent target to a best target within the touch area. TouchEvent coordinates will not be changed.
• Treat long-press as a user gesture: Long-press is now considered a user gesture because it indicates user interaction with the page. This allows a web app to call restricted APIs like navigator.vibrate() on long-press to match native behavior.
• WebAudio: add user selectable automation rate for AudioParams: The AudioParam.automationRate attribute allows the user to select whether the AudioParam is either “a-rate” or “k-rate”. Most but not all AudioParam attributes allow changing the rate, as given in the spec. For example, BiquadFilterNode with default “a-rate” automation is expensive to compute due to the complex relationship between the parameters and the filter coefficients. If this fast automation is not needed (the most typical case), the parameters can be set to “k-rate”.
• Improve cache management for service worker scripts: The HTTP cache will be ignored when requesting updates to the service worker. Requests for importScripts will still go through the HTTP cache. But this is just the default. A new registration option, ServiceWorkerRegistration.updateViaCache is available that offers control over this behavior. Previously, HTTP requests that checked for updates to the service worker were fulfilled by the HTTP cache by default. If a Cache-Control header was inadvertently set on a service worker, then service worker updates could be delayed, and if your service worker contained versioning information for your sites other assets, those updates would also be delayed.
• RTCRtpSender.getParameters()/setParameters() return and control track encoding: The getParameters() and setParameters() methods return or update the RTCRtpSender object’s current parameters for how the RTCRtpSender.track property is encoded and transmitted to a remote RTCRtpReceiver. These methods enable you to change encoding parameters for WebRTC streams such as the maximum transmission bitrate without doing any SDP munging or renegotiation.

For a full rundown of what’s new, check out the Chrome 68 milestone hotlist.

Google releases a new version of its browser every six weeks or so. Chrome 69 will arrive by early September.

Update: Chrome 68 for Android has also been released. It includes a fix for an Autofill issue and gives developers more control over how and when the add to home screen prompt appears. Developers can now provide additional context for their add to home screen experience, in the hopes of improving the click-through rate.

If a site meets the add to home screen criteria, Chrome will fire a beforeinstallprompt event, which lets developers add a button or other UI element to indicate it can be installed. When the user clicks through, developers can call prompt() on the saved beforeinstallprompt event to show the new add to home screen modal dialog.