Chromium Blog

Chrome 78 Beta: a new Houdini API, native file system access and more

Friday, September 20, 2019

ChromeStatus.com CSS Properties and Values

Smarter custom properties with Houdini's new API Native File Systemnow in an origin trial

The Native File System API: Simplifying access to local filesSee the Origin Trials section for information on signing up and for a list of other origin trials in this release. Origin TrialsOrigin Trials dashboardOrigin Trials Guide for Web Developers Signed Exchange Subresource Prefetching and Loading by Extending the HTTP Link Header.Signed Exchanges SMS Receiver APISMS Receiver API Other Features in this Release Apply Opacity for the Default Style of INPUT/TEXTAREA placeholderChanges the default style for ::placeholder#757575rgba(0, 0, 0, 0.54) Extend Byte-for-Byte Update Check to all Service Worker importScripts() ResourcesByte-for-byte checks are now availableimportScripts() Faster Web SocketsArrayBuffer objectsWebSocket objects

Linux: 7.5 times faster

Windows: 4.1 times faster

Mac: 7.8 times faster

More restrictive hasEnrolledInstrument() for Autofill Instrumentsrequiring unexpired cards and a billing addressPaymentRequest.hasEnrolledInstrument() PaymentResponse.prototype.retry()retry() method of a PaymentResponse Percentage Opacitysupport for percentage values to the opacity propertiesopacitystop-opacityfill-opacitystroke-opacityshape-image-thresholdopacity: 50%opacity: 0.5rgba()rgba(0, 255, 0, 50%) Redact Address in PaymentRequest.onshippingaddresschange EventRemoves fine-grained information from the shipping addressShippingAddressChangePaymentRequest.onshippingaddresschangerecipientorganizationaddressLinephoneNumber SeekingAdds a media session action handlerseektoaction handlerseekto User Timing L3Extends the existing User Timing API

Developers can pass custom timestamps to performance.measure() and performance.mark(), so as to conduct measurement across arbitrary timestamps.

Developers can report arbitrary metadata with performance.mark() and performance.measure(), which provides rich data to analytics via a standardized API.

Deprecations, and Removals XSS Auditorhas been removed from Chrome

Experimenting with same-provider DNS-over-HTTPS upgrade

Tuesday, September 10, 2019

Update: Due to a last minute technical issue, we have postponed this experiment to Chrome 79.
As part of our long standing commitment to making the web safer to use, we will be conducting an experiment to validate our implementation of DNS-over-HTTPS (aka DoH) in Chrome 78. As the name implies, the idea is to bring the key security and privacy benefits of HTTPS to DNS, which is how your browser is able to determine which server is hosting a given website. For example, when connected on a public WiFi, DoH would prevent other WiFi users from seeing which websites you visit, as well as prevent potential spoofing or pharming attacks. This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active.
More concretely, the experiment in Chrome 78 will check if the user’s current DNS provider is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service from the same provider. If the DNS provider isn’t in the list, Chrome will continue to operate as it does today. The providers included in the list were selected for their strong stance on privacy and security, as well as the readiness of their DoH services, and also agreed to participate in the experiment. The goals of this experiment are to validate our implementation and to evaluate the performance impact.
Our experiment will run on all supported platforms (with the exception of Linux and iOS) for a fraction of Chrome users. On Android 9 and above, if the user has specified a DNS-over-TLS provider in the private DNS settings, Chrome may use the associated DoH provider, and will fallback to the system private DNS upon error.
By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same. For instance, malware protection or parental control features offered by the DNS provider will continue to work. If DoH fails, Chrome will revert to the provider’s regular DNS service. Opting-out of the experiment will be possible from Chrome 78 by disabling the flag at chrome://flags/#dns-over-https.
Most managed Chrome deployments are excluded from the experiment. For enterprise and education customers, we invite administrators to read the upcoming release notes for details about DoH policies which will be published on our Chrome Enterprise blog.
With 35 years of history, DNS is used by multiple parties, and enables diverse use cases. In particular, we are aware of how DNS can play an important role in ISP-provided family-safe content filtering. So, we are and will continue to take an incremental approach where we respect any active user-facing features such as family-friendly filters, with steps informed by discussions involving key stakeholders, e.g. ISPs, DNS providers, and organizations with expertise in online safety. We will also take into account performance and reliability statistics sent by users who have agreed to help improve Chrome’s features and performance, as well as user feedback.
This experiment is the humble first step of a long collaborative journey to improve our users’ privacy, security, and safety. We can’t wait to see how DoH performs in the wild, and welcome your feedback!
Kenji Baheux, Chrome Product Manager

Potential uses for the Privacy Sandbox

Thursday, August 22, 2019

outlined our visiona series of explainers User information

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

Chrome Dev Summit is now open for registration!

Tuesday, August 20, 2019

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

Chrome 77 Beta: New performance metrics, new form capabilities, capabilities in origin trials and more

Friday, August 9, 2019

ChromeStatus.com New Performance Metrics Largest Contentful Paint

Largest Contentful Paintweb.dev First Input TimingPerformanceEventTiming interface New Form Capabilities<input>formdata<input>formdataFormDataformdataMore capable form controlsweb.dev Origin TrialsOrigin Trials dashboardOrigin Trials Guide for Web Developers A Contact Picker for the WebA Contact Picker for the Web Other features in this release Enter Key Hintenterkeyhint<form>enterdonegonextprevioussearchsend Feature Policy Control over Document.domaindocument-domain policydocument.domain Layout Instability MonitoringLayoutShift Limit the "referer" Header's Length to 4kBStrips the referer header downrefererrefererno-cors Limit registerProtocolHandler() url Argument to http/https The registerProtocolHandler() New Features for Intl.NumberFormatimproves Intl.NumberFormat Overscroll Behavior Logical LonghandsCSS flow-relative propertiesflow-relativeoverscroll-behavior-inlineoverscroll-behavior-block PerformanceObserverInit Buffered FlagAdds a buffered flag to observer.observe()PerformanceObserver WebRTCRTCPeerConnection.onicecandidateerrorincecandidateerrorSTUN (RFC5389)TURN (RFC5766)RTCPeerConnection.restartIce()a method for triggering an ICE restarticeRestartcreateOffer()restartIce()signalingState Service WorkersPreserve Request Priorities through Service WorkerPreserves a request's original priorityService Workers Support Basic HTTP AuthenticationDisplays HTTP authentication dialog boxes Stop Action for Media SessionsstopMediaSessionAction MediaSession.setActionHandler()stopSamples are available Web Payments: Throw a TypeError on Invalid "basic-card" DataPaymentRequestnow throws a TypeErrorsupportedNetworkssupportedTypesW3C Payment API changes in Chrome 77 Interoperability Improvements Support Step Timing Functions jump-start|end|both|nonea richer set of step animationsjump-*jump-bothjump-nonejump-startjump-endjump-startjump-endstartend white-space: break-spacesbreak-spaceswhite-spacewhite-space: pre-wrapoverflow-wrap: break-spacestextareacontenteditablewhite-spaceword-breakoverflow-wrap Deprecations, and Removals Card Issuer Networks as Payment Method Namessupport for calling PaymentRequestsupportedMethods Deprecate Web MIDI Use on Insecure Origins will no longer be allowed Deprecate WebVR 1.1 APIdeprecated in Chromebeing replaced byWebXR Device API

Project Strobe: Updates to Our User Data Policy

Tuesday, July 23, 2019

We’re requiring extensions to only request access to the least amount of data. While this has previously been encouraged of developers, now we’re making this a requirement for all extensions.

We’re requiring more extensions to post privacy policies, including extensions that handle personal communications and user-provided content. Our policies have previously required any extension that handles personal and sensitive user data to post a privacy policy and handle that data securely. Now, we’re expanding this category to include extensions that handle user-provided content and personal communications. Of course, extensions must continue to be transparent in how they handle user data, disclosing the collection, use and sharing of that data.

Inventory your extensions' current permissions and, where possible, switch to alternatives that are more narrowly scoped. Additionally, include a list of permissions used and the reasons you require them in your Chrome Web Store listing or in an "about page" in your extension. If you expand the features of your extension and require a new permission, you may only request the new permission in the updated version of the extension.

If your extension handles Personal or Sensitive User Data, which now also includes, user-provided content and personal communications, your Product must both post a privacy policy and handle the user data securely, including transmitting it via modern cryptography. To add a privacy policy, use the developer dashboard to link to your privacy policy with your developer account. All your published extensions share the same privacy policy.

User Data FAQ.
Posted by Alexandre Blondin and Swagateeka Panigrahy, Chrome Product & Policy

Easier Payments with Chrome

Tuesday, July 2, 2019

People have high expectations for their shopping experience on the web — whether booking a vacation, or buying tickets to a hot concert before they’re gone. They want a fast, seamless, and safe experience that works across all their devices.
That’s why today we are making payments in Chrome more convenient: When you’re signed into Chrome on your laptop, you’ll be able to use payment methods previously saved to your Google Account to fill in checkout forms. And you can use this feature without having to turn on Chrome sync. You'll also be able to use the payment info you’ve saved in your Google Account across your devices in Chrome where you’re signed in, and wherever Google Pay is accepted.
You are always in control: When you’re signed-in and Chrome offers you the option of using a card from your Google Account, it will ask you to confirm the card’s CVC. If you choose to save a new card to your account, you will receive a confirmation email from Google Pay with additional information. You can manage and delete the cards in your account at anytime by going to your Google Account > Payments & subscriptions > Payment methods.

Using this new feature doesn’t turn on Chrome sync. And of course, if you prefer to save your payment methods only locally on your device, you can still do that: Add your card in Chrome Settings > Payment methods > Add. When you sign into any Google website, you’re also signed into Chrome with the same account. You can turn off "Allow Chrome sign-in" altogether in settings.

Every time you open your browser, you have a task in mind to accomplish. We’ve built Chrome to help you do that as quickly and safely as possible, whether you are completing a search, viewing a website, or making a purchase. This feature is just one more way we are improving this experience for everyone.

Posted by Sabine Borsay, Chrome Product Manager