Chromium Blog

Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky

Thursday, December 8, 2016

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

“Not Secure” warning for HTTP password and credit card pages

To help users browse safely, Chrome indicates connection security with an icon in the address bar. Historically, Chrome has not explicitly labelled HTTP connections as non-secure. Starting in version 56, Chrome will mark HTTP pages that collect passwords or credit cards as non-secure, as part of a long-term plan to mark all HTTP sites as non-secure. The feature will roll out gradually over the next few weeks.
To avoid being labeled insecure, sites should secure their traffic with HTTPS and follow general security guidelines.

Chrome ‘Not Secure’ warning appearing in the URL bar for a site with an HTTP connection
Web Bluetooth
Sites can now interact with Bluetooth Low Energy (BLE) devices using the Web Bluetooth API on Android, Chrome OS, and Mac. The Web Bluetooth API uses the GATT protocol, which enables web developers to connect to bluetooth devices such as printers and LED displays with just a few lines of JavaScript. Web Bluetooth can also be combined with Physical Web beacons to discover and control nearby devices. To get started, check out these samples and demos on GitHub.

An Android device connecting to a BLE-enabled heart rate monitor via the web (source)
CSS position: sticky
Chrome now supports CSS position: sticky, a new way to position elements. A position: sticky element is relatively-positioned, but becomes position: fixed after the user reaches a certain scroll position.

Previously, building content headers that scrolled normally until sticking to the top of the viewport required listening to scroll events and switching an element’s position from relative to fixed at a specified threshold. This solution was difficult to synchronize, resulting in small visual jumps. Now, users can achieve the desired effect by simply positioning their elements as sticky.

Other features in this release

The new Remote Playback API on Android enables sites to initiate and control playback of an HTMLMediaElement on smart TVs and speakers.

The WebVR API is available on Android as an origin trial, allowing developers to create virtual reality experiences on the web.

The WebGL 2.0 API is enabled by default on desktop platforms, providing OpenGL ES 3.0 level rendering capabilities via the <canvas> element.

Support for Adobe Flash will no longer be advertised in navigator.plugins and navigator.mimetypes if the user has not substantially interacted with a site, though users can re-enable Flash experiences on a per-site basis.

Sites can now experiment with taking photos and configuring camera settings like zoom using the Image Capture origin trial.

When content changes above the viewport, Chrome now automatically adjusts the scroll position to keep content in the viewport fixed unless the CSS overflow-anchor property is set.

The Notifications API now allows sites to include an image in notifications by setting the image property.

The PaymentRequest API has a variety of new features including requestPayerName and JSON serialization.

Showing and hiding the URL bar on mobile no longer resizes the initial containing block or elements sized with viewport units such as vh.

Text input elements such as <input type="text"> now have spell-checking enabled by default on Android devices with at least 512 MB of memory and a system dictionary.

The generic font family used to fit content within the UI has been standardized and renamed as system-ui on all platforms.

The new Referrer-Policy HTTP header allows sites to forward site traffic by URL without leaking the user’s session identifier or other private information.

KeyboardEvent.isComposing() allows sites to determine if the user is typing based on recent KeyboardEvents, without monitoring keyboard events directly.

Chrome for Android now sets the default preload attribute for videos to metadata on cellular connections, showing a preview image and time information to match other mobile browsers.

Chrome now supports TLS 1.3 and includes 1-RTT based on draft-18.

Sites can use ImageBitmapRenderingContext to reduce memory consumption and compositing overhead by rendering pixel data in the form of an ImageBitmap.

Sites can respond to pinch gestures using the pinch-zoom CSS touch-action property.

ConstantSourceNode is a new audio source node that produces a constant output mixed with an AudioParam.

Two Web Audio ChannelSplitterNode Interface attributes are now read-only: channelCount, which is defined by numberOfOutputs in createChannelSplitter(), and channelCountMode, which is set to explicit.

PannerNode.rolloffFactor now clamps to the nominal range of a PannerNode’s distance model to describe the volume reduction rate as the source moves away from the listener.

window.prompt() will no longer focus its parent tab if the page is not currently in the foreground, and the dialog will be automatically dismissed.

To match behavior on Windows, Chrome Extensions can now override default search, startup, and homepage settings on Mac with the Chrome Settings Overrides API.

Support for FLAC is enabled within the FLAC and Ogg containers for the <audio> tag and decodeAudioData().

OPUS can now be used with decodeAudioData(), expanding the variety of audio codecs supported by the WebAudio API.

Deprecations and interoperability improvements

The WebAudio API no longer includes the deprecated Doppler API, including speedOfSound, dopplerFactor, and setVelocity.

To improve standards conformance, RTCPeerConnection now accepts iceTransportPolicy as an RTCConfiguration parameter as well as iceTransports.

RTCPeerConnection is now available without a webkit prefix, though webkitRTCPeerConnection still remains.

Non-whitespace unicode control characters will now be rendered according to the specification, rather than being ignored.

The reflected-xss directive has been removed from Content Security Policy 2 since it was solely a wrapper for the X-XSS-Protection header and provided no additional functionality.

Support for the MediaStreamTrack.getSources() method has been removed in favor of MediaDevices.enumerateDevices().

The CSP referrer directive is no longer supported in favor of the new Referrer-Policy header.

ShadowDOM’s slotchange events bubble, but no longer re-fires, at a slot's assignedSlot.

Legacy CBC-mode ECDSA cipher suites ECDHE_ECDSA_WITH_AES_128_CBC_SHA and ECDHE_ECDSA_WITH_AES_256_CBC_SHA have been removed in favor of modern ciphers such as ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

ECDSA with both SHA-1 and SHA-512 have been removed to reduce dependencies on SHA-1 and align with TLS 1.3's new ECDSA handling.

Chrome no longer allows opening of pop-ups during inputs which represent a touch scroll, such as touchstart and touchmove.

Sites will no longer initiate fetches for scripts with invalid type or language attributes, such as type="python", unless triggered by declarative fetches using link preload.

MIDIMessageEvent.receivedTime has been deprecated in favor of Event.timeStamp, since Event.timeStamp now supports high-resolution monotonic time instead of epoch time.

Posted by Vincent Scheib, Web Bluetooth Orthodontist

Chrome Dev Summit 2016: The Mobile Web Moves Forward

Wednesday, November 16, 2016

Last week at the 4th annual Chrome Dev Summit, we were excited to share a glimpse of what’s possible with over 1,000 developers in person, and thousands more on the livestream. Each year this is a time to hear what developers have been building, share our vision for the future of the web platform, and celebrate what we love about the web...

Reach of the web As we've talked about before, one of the superpowers of the web is its incredible reach. There are now more than two billion active Chrome browsers worldwide, with many more web users across other browsers. The majority of these users are now on mobile devices, bringing new opportunities for us to explore as an industry.
Mobile browsers also lead the way for the internet’s newest users. Exclusively accessing the internet from mobile devices, users in emerging markets struggle with limited computing power, unreliable networks, and expensive data. For these users, native apps can be a poor match due to their large data and storage requirements. And, it’s these constraints that have resulted in the developing markets leading the charge when it comes to innovating on the web.
Progressive Instead, the web can fill these needs for all users through an experience we've been calling Progressive Web Apps (PWAs). These web apps provide the performance users have come to expect from their device, while also offering critical capabilities such as offlining, add-to-homescreen, and push notifications. We've been encouraged by the strong adoption of these capabilities, with push notifications recently exceeding 18 billion notifications per day across 50,000 domains.
Last year when we spoke about PWAs, things were just getting started. Now we're seeing the movement in full swing, with many large sites across the globe launching great new apps and feeling the success that PWAs can bring. DAY 1 - THAO LOGOS.png

Alibaba.com, built a PWA and saw a 76% increase in conversion rates across browsers. The investment in the mobile web increased monthly active user rates on iOS by 14 percent. On Android devices where re-engagement capabilities like push notifications and Add to Homescreen were enabled, active user rates increased by 30 percent.

Another great example is The Weather Channel. Since launching a PWA they achieved an 80% reduction in load time and within three months, saw almost 1 million users opt in to receive web push notifications.

During the Summit, we also heard from Lyft, who shared their experience of building a PWA in less than a month, and using less than a quarter of the engineering support needed to build their native app. Learn more about our how partners are using PWA technologies to enhance their mobile web experience.

What can you do? We also have a variety of tools, libraries, and APIs available to help you bring the benefits of PWAs to your site. For example, Chrome's DevTools provides assistance along every step of the development flow. DevTools has a ton of new features to help you build great mobile apps, such as network simulation, CPU throttling, and a PWA audit tool powered by Lighthouse.

For developers just beginning their web app or looking to rework an existing one, the Polymer App Toolbox provides a set of components and tools for easily building a Progressive Web App using web components. And Polymer 2.0 is right around the corner, making it easy to take advantage of the new Web Components v1 APIs shipping cross-browser and build mobile web apps with minimal overhead.

Finally, checkout can be a complicated process to complete and in the retail sector alone there are 66% fewer conversions on mobile than on desktop. With PaymentRequest, you can now bring a seamless checkout experience to your website with support for both credit cards and Android Pay, increasing odds for conversion.

Catch up Finally, if you didn’t catch our live stream in real time, you can always check back on our YouTube channel for all the recordings or see the highlights from the event in 57 seconds.

Thanks for coming, thanks for watching, and most of all, thank you for developing for the web!
Posted by Darin Fisher, VP Engineering, Chrome

Here’s to more HTTPS on the web!

Friday, November 4, 2016

Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we’ve worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It’s happening now, with secure browsing becoming standard for users of Chrome.

Today, we’re adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory. Chart

Percentage pages loaded over HTTPS in Chrome
As the remainder of the web transitions to HTTPS, we’ll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.

As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we’ve posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.

We’ve seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented “we were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS.” CNET, a large tech news site, had a similar experience. “We successfully completed our move of CNET.com to HTTPS last month,” said John Sherwood, Vice President of Engineering & Technology at CNET. “Since then, there has been no change in our Google rankings or Google organic search traffic.”

Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, “saw no material impact to AdX revenue with the transition to SSL.”

As migrating to HTTPS becomes even easier, we’ll continue working towards a web that’s secure by default. Don’t hesitate to start planning your HTTPS migration today!
Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team

Chromium Blog

Chrome 56 Beta: “Not Secure” warning, Web Bluetooth, and CSS position: sticky

Chrome Dev Summit 2016: The Mobile Web Moves Forward

Here’s to more HTTPS on the web!

Labels

Archive

Feed