Chromium Blog: September 2019

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

Feb	MAR	Apr
	19
2020	2021	2022

Chromium Blog

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

Experimenting with same-provider DNS-over-HTTPS upgrade

Labels

Archive

Feed