[go: up one dir, main page]

Historically, running native code on the web required a browser plugin. In 2013, we introduced the PNaCl sandbox to provide a means of building safe, portable, high-performance apps without plugins. Although this worked well in Chrome, it did not provide a solution that worked seamlessly across all browsers.


Since then the web community has rallied around WebAssembly, as a cross-browser solution to high performance code. WebAssembly provides the speed necessary to build an in-browser video editor or run a Unity game at a high frame rate utilizing existing standards-based web platform APIs. Applications using WebAssembly already run in multiple browsers: Chrome and Firefox support WebAssembly natively and Edge and Safari support WebAssembly in preview versions of their browsers.


Given the momentum of cross-browser support, we plan to focus our native code efforts on WebAssembly going forward. We will remove support for PNaCl in the first quarter of 2018 everywhere except inside Chrome Apps and Extensions. We believe that the ecosystem around WebAssembly makes it a better fit for new and existing high-performance web apps, and that usage of PNaCl is sufficiently low to warrant deprecation.


We recognize that technology migrations can be challenging. To help ease the transition we have prepared a set of recommendations for existing PNaCl implementations to migrate to the web platform, as well as a feature roadmap for WebAssembly. As you embark on the migration process, please let us know if you run into any challenges, so that we can help make the shift as smooth as possible.


With the launch of WebAssembly, the web platform has gained a foundation for a new generation of fast and immersive web apps that run in any browser. We’re excited to see what developers build next!



Posted by Brad Nelson, Software Engineer on NaCl, PNaCl, and WebAssembly

Posted by Rahul Roy-chowdhury, VP Product Management, Chrome


What a difference a year makes. Last year at Google I/O, we shared that the mobile web was open for business. New technologies such as AMP and Progressive Web Apps (PWAs) were bringing new capabilities, better performance, and a streamlined workflow to the mobile web.


Fast forward one year later: more than two billion AMP pages have been created and "PWA" has proved to be far more than a buzzword—it’s now the way that many businesses around the world are building for mobile devices. For more details, take a look at the video from Google I/O on the latest mobile web state of the union, or read below on how these technologies are making the modern mobile web mainstream.


Momentum
Summing up all the great success stories from around the world in a single post is a tall order, but here are some highlights.


To improve the performance of Wego's mobile site, the company built AMP pages using amp-install-serviceworker to transition to a fast PWA experience. Average page load time decreased from 12 seconds to less than one second, and conversion rates increased by 95%.


When Forbes rebuilt their mobile website as a PWA, they began by re-thinking what their experience could look like on a phone. Instead of minimally updating their underlying site, Forbes integrated PWA technologies to provide an immersive, app-like experience. They saw immediate improvements and engagement rates have more than doubled since launch.



Ola, the leading cab aggregator in India, built a PWA and noticed that 20% of users who book using their PWA had previously uninstalled their app. By reducing the amount of storage space needed, the PWA allowed them to effectively re-engage with users that otherwise would have been lost.


Another success story is Twitter Lite, a PWA which minimizes data usage, is resilient on unreliable mobile networks, and is less than 1MB of space on a device. Twitter's new mobile experience is also optimized for speed, with up to 30% faster launch times as well as quicker navigation throughout the site. They've found that users are spending 2.7x more time on site, and as a result are seeing 76% more tweets on the new PWA than their previous mobile site. Twitter is seeing incredible re-engagement with 1 million sessions initiated a day from icons added to the Android homescreen.


Polished Experiences
Users expect a lot from their mobile devices, and we've added tons of APIs over the past year to meet that demand. The mobile web can support more use cases and get more done than ever before. A few highlights:

  1. Improved Add to Homescreen
Earlier this year we unveiled Improved Add to Homescreen, integrating PWAs much deeper into the Android operating system. Now, in addition to being displayed on the homescreen, PWAs are also displayed in the app launcher and Android settings alongside native apps, and can also open in response to users clicking links in Chrome or other apps.

  1. Payments
Checkout can be a complicated process. To improve payment flows on the web, we launched a one-tap payment API called Payment Request. Using this API allows web apps to support credit cards and Google payment mechanisms such as Android Pay. We also just announced that it is now possible to integrate this API with additional payment apps.

  1. Media Consumption
Over 70% of internet traffic is video. To allow great mobile web media experiences we have given the users more control over playback with the Media Session API, improved full screen playback with the Screen Orientation API, and we’re filling out features for offline with Background Fetch. To learn more, see our mobile web media best practices and see how the APIs can come together at our PWA for Media demo.



Tooling
We’ve also been working hard to improve and extend the set of tools that let you build engaging experiences on the web.


Lighthouse is a new automated tool for measuring the quality of a web experience. It runs nearly 100 audits against your web app, checking everything from page performance, to byte efficiency, to accessibility, and gives you a summary score. New integration with Chrome's DevTools means you’ll be able to run Lighthouse audits without leaving the browser.


Polymer 2.0 is the next major release of the Polymer library, re-built from the ground up to take advantage of the best new features of the modern web platform. This release uses new Web Component API’s that have shipped in Chrome and Safari. It’s completely modular and best of all - it’s now 10% faster and 80% smaller.


Chrome is committed to making sure that you can develop easily, engage with your users, and build a thriving business around the web. For the latest news, subscribe to our YouTube channel and follow us on Twitter @ChromiumDev.


Welcome to Google I/O 2017! Today at 4PM Pacific Daylight Time, Rahul Roy-chowdhury, VP Product Management for Chrome, will be on stage at Google I/O discussing The Mobile Web: State of the Union. Tune into the livestream below, and if you happen to be attending Google I/O, be sure to come to the Amphitheatre to see it live!


Posted by Ryan Schoen, Product Manager

Security is critical to Chrome, and many features protect Chrome users as they browse the web. Google Safe Browsing warns users away from websites known to be dangerous. Chrome’s sandbox and multi-process architecture provide additional layers of defense by helping block malware installation and reducing the severity of vulnerabilities. In Chrome 56, we've added yet another layer of defense by fully isolating Chrome extension privileges from web pages.


Chrome has always kept extensions and web pages in different processes where possible, but sometimes extensions host web content in iframes. For example, an extension's options page may include social network buttons or ads. Until recently, these web iframes ran inside the extension's process. This is usually safe because security checks inside that process do not allow web iframes to use extension APIs. However, in rare cases malicious web iframes could exploit bugs to bypass these checks and use the same privileged APIs that are available to extensions, like chrome.history.


Chrome now uses out-of-process iframes to ensure that extension-hosted web iframes are never put into their parent extension process. Even if an extension's web iframe finds a Chrome bug and takes over its own web process, that process won't have access to extension APIs.

With this launch, web iframes in extension pages now run in a separate process from the extension, adding an extra layer of protection to privileged APIs.


Introducing out-of-process iframes will greatly strengthen Chrome's security model, though building them required a large change to Chrome's architecture affecting systems like painting, input events, and navigation. This launch is just the first phase of our Site Isolation project, so stay tuned for even more security improvements that out-of-process iframes make possible.



Posted by Charlie Reis, Site Isolator

Unless otherwise noted, changes described below apply to the newest Chrome Beta channel release for Android, Chrome OS, Linux, Mac, and Windows.
Headless Chromium
Headless Chromium allows running Chromium in an automated environment without a user interface or peripherals. This enables use cases such as automating unit tests with Selenium and converting a web page into a PDF.



Headless Chromium is powered by all the modern web platform features provided by Chromium and Blink. Support is now available on Mac and Linux, with a Windows implementation coming soon.
Native notifications on macOS
Chrome has historically included its own notification system for web and extension developers to send notifications to users. In response to macOS introducing its own rich notification system, many users have asked for the two systems to be integrated.  
In Chrome 59, when developers send notifications via the Notifications API or chrome.notifications, they will be shown directly by the macOS native notification system. This change improves the user experience, but some low-usage API features are now discouraged since they result in a degraded experience on macOS, as documented in the migration guide.
TMPNOTIF.png
Chrome notifications before and after integration with the native notification system.
Service worker navigation preload
The Service Worker navigation preload API enables the browser to preload navigation requests while a service worker is starting up. These requests are started before executing the fetch event handler in the service worker intercepting the target URL. This gives the worker access to the preload response inside the fetch event handler, allowing the service worker to handle the navigation with minimal delay.
Other features in this release
  • Developers can now use MediaError.message to obtain greater detail about a MediaError produced by <audio> or <video>.
  • WritableStreams are now available as part of the Streams API for processing streams of data, while providing a standard abstraction for writing streaming data to a sink with built-in backpressure and queuing.
  • The Streams API has been expanded with the ability to pipe between ReadableStreams and WritableStreams via the pipeTo() and pipeThrough() methods, allowing easier consumption of streaming data.
  • Developers can now use the getInstalledRelatedApps function to smartly consolidate push notifications between related web and native apps by suggesting when and on which platform to offer them.
  • The Image Capture API now allows sites to take higher resolution images than before, providing full control over camera settings such as zoom, ISO, and white balance.
  • To provide enhanced privacy, CSS stylesheets can now specify their own referrer policy via the HTTP header, rather than always inheriting the referrer policy of the document that originally referenced it.
  • To avoid over-prompting users, Chrome will now temporarily stop an origin from requesting a permission following the third dismissal of that permission request.
  • Touch events are now aligned to requestAnimationFrame, ensuring that input is processed as part of the document lifecycle and creating a more efficient and adaptive input response.
  • The new worker-src Content Security Policy directive restricts which URLs may be loaded as a Worker, SharedWorker, or ServiceWorker.
  • The Presentation Receiver API is now available, enabling a web page to be presented and developers to interact with the presenting web page.
Deprecations and interoperability improvements
  • The <dialog> element has changed from display: inline to block by default to better align with the spec.
  • Following removal from the Media Queries spec, support for hover: on-demand and any-hover: on-demand media queries have been removed.
  • To better align with spec and help avoid race conditions, decodeAudioData now detaches the given ArrayBuffer before decoding, removing all content from the object and making it unable to be reused or examined.
  • To increase security, Chrome no longers supports requesting notification permission over HTTP.
  • The -internal-media-controls-cast-button CSS selector has been removed in favor of the Remote Playback API.
  • The -internal-media-controls-text-track-list* CSS selectors have been removed in favor of custom-built video controls.
  • The SVGTests.requiredFeatures attribute has been deprecated following its removal from the spec.
  • initDeviceMotionEvent() and initDeviceOrientationEvent() were removed in favor of DeviceOrientationEvent() and  DeviceMotionEvent(), following a spec trend of moving away from initialization functions and toward constructors.
  • To preserve consistency across browsers, the sample property will now be included in a violation report (and associated SecurityPolicyViolationEvent object) if a report-sample expression is present in the violated directive.
  • To increase security, Chrome will now block requests for subresources that contain embedded credentials, and instead handle them as network errors.
  • To increase security, Chrome will now block requests from HTTP/HTTPS documents to ftp: URLs.
  • To preserve consistency across browsers, injecting JavaScript via AppleScript is longer supported in Chrome for Mac.
  • The ability to call Notification.requestPermission() from non-main frames has been deprecated to align the requirements for notification permission with requirements for push notifications, and ease friction for developers.
  • Support for Shared Dictionary Compression (SDCH) has been disabled until a stable API has been standardized.

Posted by Sami Kyostila, Headless Honcho
Labels: