Today on The Keyword, we outlined our vision for an initiative aimed at evolving the web with architecture that advances privacy, while continuing to support a free and open ecosystem. In order to work toward that vision, we have begun publishing a series of explainers that are intended to be shared and iterated on across the community.

Below, we’ve summarized each of these early proposals, which we are collectively referring to as the Privacy Sandbox.

User information

First, let’s identify how user information is currently used in the ad ecosystem so that we can explore the development of the Privacy Sandbox’s privacy preserving APIs.

Ad Selection

One of the most challenging questions is what your browser could do to allow a publisher to pick relevant content or show a relevant ad to you, while sharing as little information about your browsing history as possible.

We're exploring how to deliver ads to large groups of similar people without letting individually identifying data ever leave your browser — building on the Differential Privacy techniques we've been using in Chrome for nearly 5 years to collect anonymous telemetry information. New technologies like Federated Learning show that it's possible for your browser to avoid revealing that you are a member of a group that likes Beyoncé and sweater vests until it can be sure that group contains thousands of other people.

Conversion Measurement

Publishers and advertisers need to know if advertising actually leads to more business. If it’s driving sales, it’s clearly relevant to users, and if it’s not, they need to improve the content and personalization to make it more relevant. Users then benefit from ads centered around their interests, and advertisers benefit from more effective advertising.

Both Google and Apple have already published early stage thinking to evaluate how one might address some of these use cases. These proposals are a first step in exploring how to address the measurement needs of the advertiser without letting the advertiser track a specific user across sites.

Fraud Prevention

Publishers today often need to detect and prevent fraudulent behavior, for instance false transactions or attempts to fake ad activity to steal money from advertisers and publishers. Many companies, including Google, work to detect and prevent fraud, and that’s especially true of ad companies and ad fraud.

Some of the tools used to legitimately fight fraud today use techniques that can benefit from using more privacy safe mechanisms. One example is the PrivacyPass token, introduced by CloudFlare for Tor users, which is now moving through the standards process.

Protecting the Sandbox Boundary

Our experience has shown us that removing certain capabilities from the web causes developers to find workarounds to keep their current systems working rather than going down the well-lit path. We’ve seen this recently in response to the actions that other browsers have taken to block cookies - new techniques are emerging that are not transparent to the user, such as fingerprinting.

With fingerprinting, developers have found ways to learn tiny bits of information that vary between users, such as what device they have or what fonts they have installed. By combining several of these small data points together they can generate a unique identifier which can then be used to match a user across websites. Unlike cookies, users cannot clear their fingerprint, and this means that even if a user wishes not to be identified, they cannot stop the developer from doing so. We think this subversion of user choice is wrong.

As referenced in May at I/O, we are actively taking steps to prevent fingerprinting. We are proposing the implementation of what we call a privacy budget. With a privacy budget, websites can call APIs until those calls have revealed enough information to narrow a user down to a group sufficiently large enough to maintain anonymity. After that, any further attempts to call APIs that would reveal information will cause the browser to intervene and block further calls.

We appreciate you taking the time to read through our early proposals for building the Privacy Sandbox. We understand it is ambitious and can’t overstate how important it is that this be refined and improved as a result of collaboration across the industry, including other browsers and publishers. We look forward to hearing your thoughts!

Posted by Justin Schuh - Director, Chrome Engineering

We’re excited to announce that registration for the seventh Chrome Dev Summit is now open and you can request your invite here today! During the Summit, we will share our vision for and updates on our work towards moving the web platform forward and of course, have a bit of fun. ‘Cuz what’s Chrome Dev Summit, without some fun? 

Event details:

Date: Nov 11-12, 2019

Venue: Yerba Buena Center for the Arts in San Francisco, CA

What’s happening?

Over the two days, we will focus on the latest best practices, tools and updates coming to the web platform and give developers a chance to hear directly from the Chrome product engineering teams. 

Similar to last year, we’ll have a single track of content in one hall so everyone can enjoy all the sessions and have meaningful discussions. We’re also bringing back the Forum where you’ll be able to enjoy demos of the latest web technologies and developer tools as well as engage with the Chrome team as well as folks from the community.

We’ll be adding more details on the event site, as we move closer to the event, so watch out for more in the coming weeks and months.

Can’t attend in person? 

As always, we want to ensure that Chrome Dev Summit stays inclusive and exciting for everyone, regardless of whether you’re joining us in person or online. We’ll be livestreaming the entire two days of content for our online attendees and will also include some exciting livestream-only content. 

Sign up here so we can send you updates on the livestream and other related info around the event.

The Chrome team is committed to making the Web the best platform to give everyone in the world universal access to content and apps. We want to make it easier for developers to bring best-in-class content and experiences to their users, by making it more powerful and by reducing the cost of development. And we hope to do this as responsible citizens of the community, working with others to uphold our principles of promoting the open web.

We look forward to seeing you in San Francisco for yet another awesome Chrome Dev Summit!

Posted by Paul Kinlan, Content-Herder-and-Speaker-Wrangler-in-Chief

Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 77 is beta as of August 8, 2019.

New Performance Metrics

Largest Contentful Paint

It has not always been easy for developers to measure how quickly the main content of a web page loads and is visible to users. The usefulness of existing metrics varies. Some metrics are only measurable in a lab, while others tell nothing about content that users care about. Consider the example below, taken from a DevTools performance audit. At the time of the first contentful paint, there's no content on screen that a user can interact with.



Largest Contentful Paint attempts to provide more meaningful data by using the largest content element as a proxy for when the main content of the page is likely visible to users.

You're probably asking questions like what does the new metric track? When is the metric reported? How do I improve it if it's slow? For answers to these and other questions, see "Largest Contentful Paint" on web.dev.

First Input Timing

The PerformanceEventTiming interface provides timing information about the latency of the first discrete user interaction, specifically one of key down, mouse down, click, or the combination of pointer down and pointer up. Pointer down may be the start of scrolling, which is not tracked. This is a subset of the EventTiming API, but will be exposed in advance because it provides key metrics to help measure and optimize responsiveness.

New Form Capabilities

Many websites use custom form controls to either add features that aren't available in standard controls or to tailor a form's design. A drawback of custom controls is that data must be stored in hidden <input> elements.

Two new features support custom form controls. The formdata event lets sites use JavaScript instead of hidden <input> elements to add data to a form. With this feature, site builders add a formdata event listener to a form element. The passed event includes a FormData object containing the data being submitted, which can now be modified.

The formdata event only lets sites interact with the submission process. Form-associated custom elements let site creators build custom elements that act like built-in form controls, providing capabilities such as enabling input validation or submitting data to the server.

To learn more and to see example code, read More capable form controls on web.dev.

Origin Trials

This version of Chrome introduces the origin trials listed below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones listed below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.

A Contact Picker for the Web

The Contact Picker API is a new, on-demand picker that allows users to select entries from their contact list and share limited details of the selected entries with a website. It allows users to share only what they want, when they want, and makes it easier for users to reach and connect with their friends and family. See A Contact Picker for the Web for details.

Other features in this release

Enter Key Hint

The enterkeyhint content attribute
is an enumerated attribute for <form> elements that specifies what action label (or icon) to present as the enter key on virtual keyboards. This allows authors to customize the presentation of the enter key to make it more helpful for users. The attribute takes one of enter, done, go, next, previous, search, or send.

Feature Policy Control over Document.domain

The document-domain policy governs access to document.domain. It is enabled by default, and, if disabled, attempting to set document.domain will throw an error.

Layout Instability Monitoring

Adds the LayoutShift interface
to the Performance API, allowing developers to monitor changes to a DOM element's on-screen position.

Limit the "referer" Header's Length to 4kB

Strips the referer header down to an origin when it's size exceeds 4kB.
Servers will often behave in unexpected ways when presented with an overly-long referer header. This is unfortunate, because referer is one header whose length attackers generally retain control over when generating no-cors requests.

Limit registerProtocolHandler() url Argument to http/https

The registerProtocolHandler() now only accepts URLs with http or https schemas. Because the intent of the API is to allow an endpoint to handle something like an SMS message, for example, it doesn't make much sense for handlers to be data URLs, blob URLs, and so on.

New Features for Intl.NumberFormat

This change improves Intl.NumberFormat by adding support for measurement units, currency and sign display policies, and scientific and compact notation.

Overscroll Behavior Logical Longhands

Adds CSS flow-relative properties for controlling overscroll behavior through logical dimensions. flow-relative properties are those that are interpreted relative to the flow of content. The new properties are overscroll-behavior-inline and overscroll-behavior-block.

PerformanceObserverInit Buffered Flag

Adds a buffered flag to observer.observe() so that PerformanceObserver can receive entries created before the call is executed.

WebRTC

RTCPeerConnection.onicecandidateerror
Adds the incecandidateerror event which provides detailed information about WebRTC ICE candidate gathering failures, including the ones defined by STUN (RFC5389) and TURN (RFC5766).

Diagnosing ICE connectivity issues without access to detailed gathering failures can be a challenge. Support for ICE candidate errors is targeted towards better connectivity troubleshooting and network diagnostics.

RTCPeerConnection.restartIce()
Adds a method for triggering an ICE restart which causes a WebRTC connection to try to reconnect. This feature is already available in Chrome by passing the iceRestart argument to createOffer(). restartIce() is a version of this method that works regardless of signalingState.

Service Workers

Preserve Request Priorities through Service Worker
Preserves a request's original priority when it passes through a service worker. Previously, all requests going through a service worker would get "High" priority. This means render-blocking style sheets would have their priority clamped, while less important resources would get boosted.

Service Workers Support Basic HTTP Authentication
Displays HTTP authentication dialog boxes even if the request was from a service worker. This shows the native login dialog shown when an HTTP 401 response is received.

Stop Action for Media Sessions

Adds stop as a MediaSessionAction for calls to MediaSession.setActionHandler(). An action is an event tied specifically to a common media function such as pause or play. The stop action handler is called when the site should stop the playback and clear the state if appropriate. Samples are available on GitHub.

Web Payments: Throw a TypeError on Invalid "basic-card" Data

The PaymentRequest constructor now throws a TypeError when invalid supportedNetworks or supportedTypes are specified for basic card payment.

See Deprecations and Removals for an additional Web Payments update item. For more about recent web payments updates, see W3C Payment API changes in Chrome 77.

Interoperability Improvements

Support Step Timing Functions jump-start|end|both|none

Adds support for a richer set of step animations. Firefox already supports jump-* step timing functions. The step timing functions jump-both, jump-none, jump-start and jump-end were introduced to the spec for easing functions in 2018. Two of these, jump-start and jump-end are aliases for start and end. The remaining two provide increased flexibility for step transitions by enabling step functions in which both or neither endpoint has a discontinuous step. Previously, one and only one of the two endpoints could have a step discontinuity. Adding support in Chromium improves cross-browser interoperability.

white-space: break-spaces

Adds the break-spaces value for the white-space property which specifies that any sequence of preserved white space that would otherwise overflow a line and hang (as per the CSS Text Module spec's Trimming and Positioning rules) must be broken.

With white-space: pre-wrap it's possible to wrap and preserve white space sequences in the middle of a text line. However, if there is a sequence at the end of the line, it either collapses or hangs, maybe overflowing its box area. The new value overflow-wrap: break-spaces allows authors to wrap and preserve these white space sequences. This can be also useful for textarea or contenteditable elements, so that white space sequences added by spacebar press events are handled properly and generate line breaks if needed. Finally, there is an ongoing effort to enhance interoperability of the line breaking CSS properties (white-space, word-break and overflow-wrap) and this new value was defined precisely to achieve that.

Deprecations, and Removals

Card Issuer Networks as Payment Method Names

Remotes support for calling PaymentRequest with card issuer networks (e.g., "visa", "amex", "mastercard") in the supportedMethods field.

Deprecate Web MIDI Use on Insecure Origins

Web MIDI use is classified into two groups: non-privilege use, and privilege use with sysex permission. Until Chrome 77, only the latter use prompts users for permission. To reduce security concerns, permissions will always be requested regardless of sysex use. This means that using Web MIDI on insecure origins will no longer be allowed.

Deprecate WebVR 1.1 API

This API is now deprecated in Chrome, being replaced by the WebXR Device API, which is expected to ship in Chrome 78. The WebVR Origin Trial ended on July 24, 2018.

WebVR was never enabled by default in Chrome, and was never ratified as a web standard. The WebXR Device API is the replacement API for WebVR. Removing WebVR from Chrome allows us to focus on the future of WebXR and remove the maintenance burden of WebVR, as well as reaffirm that Chrome is committed to WebXR as the future for building immersive web-based experiences. Removal is expected in Chrome 79.