Chromium Blog: October 2019

Chrome 79 Beta: Virtual Reality Comes to the Web

Thursday, October 31, 2019

ChromeStatus.com Virtual Reality Comes to the WebVirtual reality comes to the web

Origin TrialsOrigin Trials dashboardOrigin Trials Guide for Web Developers Support for rendersubtree Attribute rendersubtree attribute"invisible""activatable" Wake Lock API based on Promisesupdate of the Wake Lock API Other Features in this Release Adaptive Icon Display for Installed PWAs on Androidadaptive iconsAdaptive icon support in PWAs with maskable icons Autofocus Support for any Focusable HTML/SVG ElementAdds the autofocus attributeautofocusautofocus Compute img/video Aspect Ratio from Width Or Height HTML Attributes is now computed font-optical-sizingfont-optical-sizing list-style-type: <string>arbitrary character for the list style markerlist-style-typediscdecimal::beforelist-style-position Reject Worklet.addModule() with a More Specific ErrorWorklet.addModule()a more specific error objectWorklet.addModule()Worklet.addModule()AbortErrorWorklet.addModule()SyntaxError Retrieve a Service Worker Object Corresponding to a Worker Itselfnow get its ServiceWorker objectself.serviceWorkerself.serviceWorker.state Stop Evaluating Script Elements Moved Between Documents During Fetchingno longer evaluateserrorload<script><script> Deprecations, and Removalscurrent deprecationsprevious removals -webkit-appearance Keywords for Arbitrary Elements Changes -webkit-appearance keywords

Addressing some misconceptions about our plans for improving the security of DNS

Monday, October 28, 2019

DNS-over-HTTPSInternet standards communityman-in-the-middleorganizationsjournalistsinternet service providersmisinformation and confusionapproximately 97% of user DNS needsa list of participating DoH-compatible providersDoH servicesaid last monthfrom our users

Automatically lazy-loading offscreen images & iframes for Lite mode users

Thursday, October 24, 2019

In Chrome 76, we introduced native lazy-loading for images and iframes via the `loading` attribute - a developer opt-in. In Chrome 77, Chrome Android users with Lite Mode (Data Saver) enabled will benefit from native lazy-loading of images and iframes automatically.

Lite mode has allowed Chrome to reduce users’ data usage by up to 60 percent, often by compressing the pages users request before downloading them.

Web pages commonly have images or embedded content that is out-of-view near the bottom of the page, and users typically don’t scroll all the way down to discover them. Today, devices need to use resources loading this content, which is challenging for users on a limited data-plan or with a spotty network connection.

When a user has Lite Mode enabled on Chrome for Android, Chrome will defer the load of below-the-fold images and iframes until the user scrolls near them. This is done without requiring developer action. Automatic lazy-loading helps to reduce network data use and memory use. It may also increase site speed, by prioritizing content visible to the user.

In our experiments, native lazy-loading of images and iframes yields a ~10% reduction in bytes downloaded per page at the 75th percentile and an 8% reduction in overall downloaded bytes for the median user. Automatic lazy-loading also led to a 1-2% improvement in First Contentful Paint at the median, a 2% improvement in First Input Delay at the 95th percentile and a 0.7% improvement in median memory reduction per page. We expect increased benefits as we tune the feature.

Chrome’s native lazy-loading has different distance thresholds after which deferred content will start loading, based on factors such as the effective connection type. This distance is chosen so that content we’ve deferred almost always completes loading by the time it becomes visible.

Any <iframe> or <img> with the `loading` attribute value of `auto` will also be eligible for Lite Mode’s automatic lazy-loading. This includes <picture> elements and CSS background images.

It is important to note that automatic lazy-loading of images and iframes is only done if a user has Lite Mode enabled. Lite Mode is most heavily used in areas of the world with poor and expensive connectivity and we believe it is users in these regions that will benefit the most from the feature. Sites wishing to learn what percentage of users have Lite Mode turned on can monitor truthy values from the SaveData JavaScript API in their analytics.

To enable Lite mode, select Settings > Lite mode and toggle the setting to On. We look forward to this feature helping users keep their page loads just a little bit lighter.

Posted by Addy Osmani, Scott Little and Raj T - lazy Chrome engineers.

Developers: Get Ready for New SameSite=None; Secure Cookie Settings

Wednesday, October 23, 2019

UPDATE (10/28/2019): We've revised the 2nd and 3rd bullet points in the section "How to Prepare; Known Complexities" below.
announcedspecongoing effortSameSite Cookies Explained Understanding Cross-Site and Same-Site Cookie Contextcross-site“third party”

When an external resource on a web page accesses a cookie that does not match the site domain, this is cross-site or “third-party” context.

same-site“first party”

When a resource on a web page accesses a cookie that matches the site the user is visiting, this is same-site or “first party” context.

A New Model for Cookie Security and Transparency

Today, if a cookie is only intended to be accessed in a first party context, the developer has the option to apply one of two settings (SameSite=Lax or SameSite=Strict) to prevent external access. However, very few developers follow this recommended practice, leaving a large number of same-site cookies needlessly exposed to threats such as Cross-Site Request Forgery attacks.

To safeguard more websites and their users, the new secure-by-default model assumes all cookies should be protected from external access unless otherwise specified. Developers must use a new cookie setting, SameSite=None, to designate cookies for cross-site access. When the SameSite=None attribute is present, an additional Secure attribute must be used so cross-site cookies can only be accessed over HTTPS connections. This won’t mitigate all risks associated with cross-site access but it will provide protection against network attacks.

Beyond the immediate security benefits, the explicit declaration of cross-site cookies enables greater transparency and user choice. For example, browsers could offer users fine-grained controls to manage cookies that are only accessed by a single site separately from cookies accessed across multiple sites.

Chrome Enforcement Starting in February 2020

With Chrome 80 in February, Chrome will treat cookies that have no declared SameSite value as SameSite=Lax cookies. Only cookies with the SameSite=None; Secure setting will be available for external access, provided they are being accessed from secure connections. The Chrome Platform Status trackers for SameSite=None and Secure will continue to be updated with the latest launch information.

Mozilla has affirmed their support of the new cookie classification model with their intent to implement the SameSite=None; Secure requirements for cross-site cookies in Firefox. Microsoft recently announced plans to begin implementing the model starting as an experiment in Microsoft Edge 80.

How to Prepare; Known Complexities

If you manage cross-site cookies, you will need to apply the SameSite=None; Secure setting to those cookies. Implementation should be straightforward for most developers, but we strongly encourage you to begin testing now to identify complexities and special cases, such as the following:

Not all languages and libraries support the None value yet, requiring developers to set the cookie header directly. This Github repository provides instructions for implementing SameSite=None; Secure in a variety of languages, libraries and frameworks.
Some browsers, including some versions of Chrome, Safari and UC Browser, might handle the None value in unintended ways, requiring developers to code exceptions for those clients. This includes Android WebViews powered by older versions of Chrome. Here’s a list of known incompatible clients.
App developers are advised to declare the appropriate SameSite cookie settings for Android WebViews based on versions of Chrome that are compatible with the None value, both for cookies accessed via HTTP(S) headers and via Android WebView's CookieManager API, although the new model will not be enforced on Android WebView until later.
Enterprise IT administrators may need to implement special policies to temporarily revert Chrome Browser to legacy behavior if some services such as single sign-on or internal applications are not ready for the February launch.
If you have cookies that you access in both a first and third-party context, you might consider using separate cookies to get the security benefits of SameSite=Lax in the first-party context.

SameSite Cookies Explained offers specific guidance for the situations above, and channels for raising issues and questions.

To test the effect of the new Chrome behavior on your site or cookies you manage, you can go to chrome://flags in Chrome 76+ and enable the “SameSite by default cookies” and “Cookies without SameSite must be secure” experiments. In addition, these experiments will be automatically enabled for a subset of Chrome 79 Beta users. Some Beta users with the experiments enabled could experience incompatibility issues with services that do not yet support the new model; users can opt out of the Beta experiments by going to chrome://flags and disabling them.

If you manage cookies that are only accessed in a same-site context (same-site cookies) there is no required action on your part; Chrome will automatically prevent those cookies from being accessed by external entities, even if the SameSite attribute is missing or no value is set. However we strongly recommend you apply an appropriate SameSite value (Lax or Strict) and not rely on default browser behavior since not all browsers protect same-site cookies by default.

Finally, if you’re concerned about the readiness of vendors and others who provide services to your website, you can check for Developer Tools console warnings in Chrome 77+ when a page contains cross-site cookies that are missing the required settings:

A cookie associated with a cross-site resource at (cookie domain) was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.”

Some providers (including some Google services) will implement the necessary changes in the months leading up to Chrome 80 in February; you may wish to reach out to your partners to confirm their readiness.

Posted by Barb Smith, Chrome and Web Platform Partnerships

Recent Site Isolation improvements

Thursday, October 17, 2019

In July 2018 we launched Site Isolation in Chrome as a way to secure desktop browsers against the risk of side-channel attacks like Spectre. We recently published a USENIX Security conference paper highlighting the benefits of this launch. Today, we are pleased to announce further improvements we've rolled out in Chrome 77:

Chrome for Android has enabled Site Isolation for sites where users enter passwords.

On desktop platforms, Site Isolation now helps defend against attacks from fully compromised renderer processes, not just side-channel attacks.

Site Isolation on Android Chrome 77 has brought Site Isolation and its benefits to Android users. Like Site Isolation on desktop, this launch leverages OS processes to make it harder for attackers to steal data from other websites. In particular, it offers the most effective defense against Spectre-like CPU vulnerabilities.
We wanted to ensure that Site Isolation does not adversely affect user experience in a resource-constrained environment like Android. This is why, unlike desktop platforms where we isolate all sites, Chrome on Android uses a slimmer form of Site Isolation, protecting fewer sites to keep overhead low. More specifically, Site Isolation is turned on only for high-value sites where users log in with a password. This protects sites with sensitive data that users likely care about, such as banks or shopping sites, while allowing process sharing among less critical sites.
Once Chrome observes a password interaction on a website, future visits to that site will be protected by Site Isolation. That means the site will be rendered in its own dedicated renderer process, walled off from other sites. Navigations to other sites will cause a tab to switch processes, and cross-site iframes are put into a different process, becoming "out-of-process iframes." Chrome keeps a list of isolated sites stored locally on the device and clears the list whenever users clear their browsing history or other site data. To bootstrap, Chrome also isolates a crowdsourced list of sites where mobile users have been entering passwords most frequently.
For the most part, Site Isolation is a behind-the-scenes architectural change that should not change the experience for users or developers. As on desktop platforms, it does cause Chrome to create more processes, which comes with performance tradeoffs: on the plus side, each renderer process is smaller, shorter-lived, and has less contention internally, but there is about a 3-5% total memory overhead in real workloads. We continue to work hard to optimize this behavior to keep Chrome both fast and secure.
In Chrome 77, password-triggered Site Isolation has been enabled for 99% of users (with a 1% holdback to monitor and improve performance) on Android devices that have a sufficient amount of RAM (currently 2GB). While we investigate how to bring this support to more devices, users who desire the most complete protection for their devices may manually opt in to full Site Isolation via chrome://flags/#enable-site-per-process, which will isolate all websites but carry higher memory cost.
In the future, we plan to add support for more ways of detecting when a site should be protected by Site Isolation. For example, we're working on allowing website operators to opt in any site to Site Isolation, without requiring user login. Containing Compromised Renderers On desktop platforms, Site Isolation in Chrome 77 now helps defend against significantly stronger attacks. Our initial launch targeted Spectre-like attacks which could leak any data from a given renderer process. Site Isolation can now handle even severe attacks where the renderer process is fully compromised via a security bug, such as memory corruption bugs or Universal Cross-Site Scripting (UXSS) logic errors.
For example, suppose an attacker discovered and exploited a memory corruption bug in Chrome's rendering engine, Blink. The bug might allow them to run arbitrary native code within the sandboxed renderer process, no longer constrained by the security checks in Blink. However, Chrome's browser process knows what site the renderer process is dedicated to, so it can restrict which cookies, passwords, and site data the entire process is allowed to receive. This makes it far more difficult for attackers to steal cross-site data.

In Chrome 77, Site Isolation helps protect many types of sensitive data from such compromised renderer processes:

Authentication: Cookies and stored passwords can only be accessed by processes locked to the corresponding site.
Network data: Site Isolation uses Cross-Origin Read Blocking to filter sensitive resource types (e.g., HTML, XML, JSON, PDF) from a process, even if that process tries to lie to Chrome's network stack about its origin. Resources labeled with a Cross-Origin-Resource-Policy header are also protected.
Stored data and permissions: Renderer processes can only access stored data (e.g., localStorage) or permissions (e.g., microphone) based on the process's site lock.
Cross-origin messaging: Chrome's browser process can verify the source origin of postMessage and BroadcastChannel messages, preventing the renderer process from lying about who sent the message.

We are continuing to improve compromised renderer protections in several ways:

Bringing these protections to Chrome for Android. This requires extra work to handle the case where only certain sites are isolated.
Protecting CSRF defenses. Sec-Fetch-Site and Origin request headers can be verified to prevent compromised renderers from forging them.
Protecting more types of data. We are investigating how to protect additional data types by default with Cross-Origin Read Blocking.
Removing exceptions. We are working to remove cases where these protections may not yet apply. For example, a small set of extensions still have broader cross-site access from content scripts, until they update to the new security model. We have already worked with extension authors to bring the affected Chrome user population down from 14% to 2%, as well as harden other extension security issues. Also, Site Isolation does not apply to Flash, which is currently disabled by default and is on a deprecation path.

We're excited about the improvements this brings to Chrome's overall security model. As a result, we are broadening the scope of the Chrome Vulnerability Reward Program to also cover cross-site data disclosure attacks that involve compromised renderers. For a limited time, security bugs affecting Site Isolation may be eligible for higher rewards than the usual amount for information disclosure bugs. We are grateful for the contributions from security researchers that we have received so far, and we look forward to working together further to improve the state of web security.

Posted by Alex Moshchuk and Łukasz Anforowicz, Site Isolators

DM Verity Algorithm Change

Wednesday, October 16, 2019

Chrome OS uses DM Verity [1] to verify the rootfs authenticity. This is to protect against malicious software such as rootkits [2], as well as accidental corruptions. The underlying structure leverages a cryptographic hash tree approach along with a kernel crypto API. With the hash tree approach individual hashes of small blocks constituting the rootfs are computed first. Then the hash tree is built up to compute and verify a final hash value [3]. This incremental approach makes the verification process less resource intensive, and consequently faster.

Until recently, the underlying hash algorithm used by DM Verity in Chrome OS has been SHA1. However, SHA1 has been found to be vulnerable to attacks a few years ago [4] and more recently research by Google and the larger security community has demonstrated that SHA1 collisions are not just theory anymore but can happen in practice [5, 6, 7]. This necessitates the replacement of SHA1 with SHA2 or SHA3 when the use scenarios makes the attacks defined in the research studies feasible.

On the other hand, the risks to DM Verity due to collision attacks are arguably low. This is because DM Verity uses a hash tree structure with disk data blocks as leaves to obtain the final hash. And to turn the collision attack into an exploit for DM Verity, the attacker would need to develop malware that would fit into a single and specific block and produce the same hash value as the original block using a chosen prefix attack. This would be computationally expensive.
We decided to proactively upgrade DM Verity in Chrome OS to use SHA256 instead. Moving to SHA256 was difficult because it is computationally more expensive than SHA1 and potentially would have increased Chromebook boot time. This is why we spent significant time tuning our implementation and measuring its performance impact on a wide range of Chromebooks to ensure that you will get very similar performance with SHA256 that you had with SHA1 when you boot your Chromebook as shown here:

Kernel boot time comparison in ms for (1)Veyron-minnie, (2)Cyan, (3)Octopus, (4)Sarien, (5)Samus, (6)Clapper, (7)Eve, (8)Bob

With this change in place your Chromebook will be safer and remain blazing fast. This migration from SHA1 to SHA256 in DM Verity is ready to go and will be on Chromebooks starting with M77.
Posted by Betul Soysal, Chrome OS security software engineer

References:

https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot
https://en.wikipedia.org/wiki/Rootkit
https://source.android.com/security/verifiedboot/dm-verity
https://en.wikipedia.org/wiki/SHA-1
Stevens, Marc, Elie Bursztein, Pierre Karpman, Ange Albertini, and Yarik Markov. "The first collision for full SHA-1.(2017)." URL http://shattered. it/static/shattered. pdf 167 (2017): 169-177.
Mezher, Monique, and Ahmed Ibrahim. "Introducing Practical SHA-1 Collisions to the Classroom." Proceedings of the 50th ACM Technical Symposium on Computer Science Education. ACM, 2019.
Leurent, Gaëtan, and Thomas Peyrin. "From Collisions to Chosen-Prefix Collisions Application to Full SHA-1." In Annual International Conference on the Theory and Applications of Cryptographic Techniques, pp. 527-555. Springer, Cham, 2019.

No More Mixed Messages About HTTPS

Thursday, October 3, 2019

Update (April 6, 2020): Mixed image autoupgrading was originally scheduled for Chrome 81, but will be delayed until at least Chrome 84. Check the Chrome Platform Status entry for the latest information about when mixed images will be autoupgraded and blocked if they fail to load over https://. Sites with mixed images will continue to trigger the “Not Secure” warning. mixed contentprogressChrome will gradually move to blocking all mixed content by default Timeline

In Chrome 79, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.

In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above.

Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the upgrade-insecure-requests or block-all-mixed-content Content Security Policy directives to avoid this warning. Here is the planned treatment:

In Chrome 81, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.

Resources for developers

Use Content Security Policy and Lighthouse’s mixed content audit to discover and fix mixed content on your site.

See this guide for general advice on migrating servers to HTTPS.

Check with your CDN, web host, or content management system to see if they have special tools for debugging mixed content. For example, Cloudflare offers a tool to rewrite mixed content to https://, and WordPress plugins are available as well.

Chrome UI for Deprecating Legacy TLS Versions

Tuesday, October 1, 2019

Update (April 6, 2020): The removal of legacy TLS versions was originally scheduled for Chrome 81, but is being delayed until at least Chrome 84. Chrome will continue to show the “Not Secure” indicator for sites using TLS 1.0 or 1.1, and Chrome 81 Beta will show the full page interstitial warning for affected sites. Our hope is that this will help alert affected site owners ahead of the delayed removal. Check the Chrome Platform Status entry for the latest information about the removal of TLS 1.0 and 1.1 support.
we announcedover 0.5% of page loads Pre-removal warning

The new security indicator and connection security information that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in January 2020. When a site uses TLS 1.0 or 1.1, Chrome will downgrade the security indicator and show a more detailed warning message inside Page Info. This change will not block users from visiting or using the page, but will alert them to the downgraded security of the connection.

Note that Chrome already shows warnings in DevTools to alert site owners that they are using a deprecated version of TLS.

Removal UI

In Chrome 81, which will be released to the Stable channel in March 2020, we will begin blocking connections to sites using TLS 1.0 or 1.1, showing a full page interstitial warning:

The full screen interstitial warning that will be shown to users who visit a site using TLS 1.0 or 1.1 starting in Chrome 81. Final warning subject to change.

Site administrators should immediately enable TLS 1.2 or later. Depending on server software (such as Apache or nginx), this may be a configuration change or a software update. Additionally, we encourage all sites to revisit their TLS configuration. In our original announcement, we outlined our current criteria for modern TLS.

Enterprise deployments can preview the final removal of TLS 1.0 and 1.1 by setting the SSLVersionMin policy to “tls1.2”. This will prevent clients from connecting over these protocol versions. For enterprise deployments that need more time, this same policy can be used to re-enable TLS 1.0 or TLS 1.1 and disable the warning UIs until January 2021.

Posted by Chris Thompson, Chrome security team

Chromium Blog