Chrome Update July 14, 2020:As of today, Chrome is restoring SameSite enforcement. It coincides with the release of Chrome v84, but is being enforced on Chrome v80+ as per the original rollout p Google announced new cookie standards in Chrome starting February 2020. Chrome SameSite update page notes that the SameSite attribute enforcement will begin on Feb 17, 2020, for a limited population. Update 2: Chrome said it is rolling back the SameSite cookie changes temporarily citing the COVID-19 situation — starting from April 3. To enforce that, they decided to change the default in the worlds most-used browser: Chrome 80 will require a newly specified setting SameSite=None to keep the old way of handling cookies, and if your omit the SameSite field like the old spec suggested, it will treat the cookie as set with SameSite=Lax.
(Last updated: Oct 01, 2020)
What: An overview of steps you can take to test your site against Chrome’s new SameSite-by-default cookie behavior, and tips for debugging cookie issues that may be related.
Who: You should read this if your site provides or depends upon cross-site cookies. Some of these tips will probably be of limited use unless you feel comfortable using Chrome DevTools, and understand what an HTTP request is and how cookies are used in HTTP requests and responses.
How: Please use Chrome 84 or newer (Beta included). (Older versions of Chrome may implement subtly different SameSite behavior, particularly for Chrome extensions, and may not include the debugging tools mentioned below.) You can check your version number by going to chrome://version.
Contents
- 1 Testing tips
- 2 Something is broken! -- Debugging tips
Testing tips
Enable the new SameSite behavior
To ensure that you are testing against the correct browser behavior, you must first enable the SameSite features directly. Please note that if you do not explicitly enable the new SameSite behavior, your browser may or may not use the new behavior (depending on whether your specific browser instance is in the control group or experimental group of the ongoing SameSite fieldtrial).
Chrome Samesite Cookie Disable
- Go to chrome://flags and enable both #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. You must set them to “Enabled” rather than “Default”.
- Restart Chrome for the changes to take effect.
- Pixelmator 2 2 1 – powerful layer based image editor. Verify that your browser is applying the correct SameSite behavior by visiting this test site and checking that all rows are green.
Chrome 84 introduces a flag called #enable-experimental-cookie-features, which enables a group of new and upcoming cookie features, including #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. This flag also removes the 2 minute 'Lax+POST' exception for top-level cross-site POST requests. This can be a convenient way to preview the future behavior of cookies in Chrome, but it may also result in unexpected behavior as the set of cookie features enabled by this flag is subject to change.
Testing your site
Thoroughly test site functionality, with a focus on anything involving federated login flows, online payments, 3-D Secure verification, multiple domains, or cross-site embedded content (iframes, images, videos, etc.).
For any flows involving POST requests (such as some login flows), we recommend that you test with and without a long (> 2 minute) delay, due to the 2 minute threshold for Lax+POST behavior (see below for more Lax+POST tips).
You will know if cookies used on your site will be affected by the new SameSite behavior if you see a banner in DevTools about issues detected while testing your site, and clicking on the banner takes you to one or more issues related to SameSite. Issues can also be viewed directly in the Issues tab, found in the three-dot menu in DevTools labeled 'More tools'. From the Issues tab, you can view the cookies triggering each warning by clicking on 'affected resources'.
Note that the presence of a cookie in an issue does not necessarily indicate that something is broken -- you must test thoroughly and determine that for yourself. Some of those blocked cookies may not affect any site functionality. Some 'legacy' cookies are also intentionally left non-compliant as a workaround for incompatible clients, and will continue to appear in the Issues tab despite the site having been updated.
Testing under Lax+POST
If your site does not use POST requests, you can ignore this section.
Chrome Same Site
![Chrome samesite=none Chrome samesite=none](https://1.bp.blogspot.com/-slb3vK96hwE/XNKfooddueI/AAAAAAAAz9E/wU9THsY6N1Mg-G-cjnWoD-byQKpmyLWjgCLcBGAs/s728-e100/google-chrome-samesite-cookies-privacy.png)
Firstly, if you are relying on top-level, cross-site POST requests with cookies then these will only be sent if they specify SameSite=None; Secure. Also consider the POST/Redirect/GET pattern as a way of removing the need for the cookie on that request. Under the new SameSite behavior, any cookie that was not set with a specified SameSite attribute value will be treated as SameSite=Lax by default, which will exclude cookies from these requests. However there is the “Lax+POST” special exception that Chrome makes for such cookies for the first 2 minutes after they are created, which allows them to be sent on top-level cross-site POST requests (which normal Lax cookies are excluded from). This special exception for fresh cookies will be phased out in future Chrome releases.
When testing, you should pay special attention to any requests that require cross-site POST requests (such as some login flows). If a cookie was granted Lax+POST due to its age (< 2 minutes), but would otherwise be blocked under Lax rules, you will most likely see a message in the DevTools console about a cookie being allowed on a non-idempotent top-level cross-site request (but in some cases you may not -- check the NetLog (see below) for the definitive answer). We recommend that you test with both a short (< 2 min) and long (> 2 min) delay between setting the cookie and making the POST request.
We also recommend testing with the eventual SameSite behavior (after Lax+POST is phased out). To do this, run Chrome from the command line with the additional flag --enable-features=SameSiteDefaultChecksMethodRigorously to disable the Lax+POST exception. (This is automatically applied if you enabled the SameSite behavior via the #enable-experimental-cookie-features flag.)
For automated testing, it may be impractical to wait for 2 minutes to test the long-delay behavior. For this purpose, you can use the command line flag --enable-features=ShortLaxAllowUnsafeThreshold to lower the 2 minute threshold to 10 seconds.
Testing Chrome extensions
Chrome extensions must also abide by the new SameSite cookie behavior. Extension pages, which have a chrome-extension:// scheme URL, are generally considered cross-site to any web page (https:// or http://). There are certain scenarios where an exception is made (this is accurate as of Chrome 80, but behavior may change in the future):
- If an extension page initiates a request to a web URL, the request is considered same-site if the extension has host permission for the requested URL in the extension’s manifest. This could happen, for example, if an extension page has an iframe embedding a site that the extension has host permission for.
- If the top level frame (i.e. the site shown in the URL bar) is an extension page, and the extension has host permission for the requested URL, and the requested URL and the initiator of the request are same-site to each other, and the extension has host permission for the initiator origin, then the request is considered same-site. For example, this could happen if an extension has host permission for “*://*.site.example/”, and an extension page loads a.site.example in an iframe, which then navigates to b.site.example.
The chrome.cookies API is able to read and set any kind of cookie, including SameSite cookies. However, a web page embedded in an extension page is considered to be in a third party context for the purposes of document.cookie (JavaScript) accesses. For content scripts, the behavior of SameSite cookies is exactly the same as if the request were initiated from the page on which the content script is running.
If your extension embeds a web page on an extension page, we recommend testing that the necessary cookies are sent on the web request. Blocked cookies should emit warning messages in the DevTools console for the extension page. If the special exceptions above apply, no message will appear.
Something is broken! -- Debugging tips
The basics
You should suspect SameSite as the underlying problem if your site makes requests to other domains in embedded contexts (such as embedded images/videos/social posts, widgets from other sites, etc.), makes POST requests cross-site (such as in some login and payment flows), fetches cross-site resources via JavaScript, or otherwise accesses cookies across sites. If the issue is primarily a browser or tab crashing or hanging, it is less likely to be caused by the new SameSite cookie behavior.
First, check if the problem persists after setting the SameSite flags above to “Disabled” (note: setting them to “Default” may or may not disable the features). Remember to restart your browser for the changes to take effect. If the problem persists, you should suspect a root cause other than the new SameSite cookie behavior.
If you have turned on third-party cookie blocking (see chrome://settings/cookies), try turning it off. This is particularly relevant for Android WebViews, which block third-party cookies by default, even if they have SameSite=None and Secure.
If you are testing in Incognito Mode, be aware that the default setting for Incognito Mode is to block third-party cookies. This can lead to behavior that appears similar to cross-site cookies being blocked due to lack of a SameSite attribute. This setting can be changed on Incognito Mode's New Tab Page, or in chrome://settings/cookies.
Try clearing your cache and cookies to see if the problem still reproduces.
Check DevTools for issues with SameSite cookies. Unfortunately, Chrome can only tell you when there are cookies that will behave differently under the new SameSite behavior, but it can’t tell you which cookies might be responsible for site breakage. However, if there are no issues about SameSite cookies on any important domains, there may be a different root cause to the problem.
(Note that prior to Chrome 85, there were messages about non-compliant cookies emitted to the JavaScript console in DevTools on each page load. In Chrome 85, these messages were removed from the console. The Issues tab is now the place to look for this information about SameSite cookies, and contains more debugging information than the console messages previously did.)
Using the DevTools Network panel
Open the Network panel in DevTools and capture the network activity that occurs when reproducing the problem. If the expected network activity is absent, reload the page by pressing Ctrl+R in DevTools. Find the request or requests that are not working properly. This may be a request that returns an error code like 403 (indicating an authentication problem, possibly caused by missing cookies), it may be highlighted in red, etc. It may be helpful to check the cookies listed in the Issues tab, as they should link directly to the affected requests (if they do not, refresh the page to ensure that the request is captured on the Network tab). Another helpful way to filter requests is to click on the 'Has blocked cookies' checkbox at the rightmost side of the toolbar with the filter box.
Click on the problematic request and go to the Cookies tab (right under the timeline, next to Headers, Preview, Response, Timing, etc.). Click on “show filtered out request cookies”. All the rows highlighted in yellow are cookies that were excluded from the request or rejected from the response for one reason or another. If you hover over the info icon on these blocked cookies, a tooltip will explain why that cookie was excluded. There may be multiple reasons why a cookie was excluded.
Look for cookies that were excluded solely for SameSite reasons. If any of these cookies are important to site functionality, their absence is likely the cause of the problem and they will need to be updated to comply with the new SameSite behavior.
Using Chrome histograms
Chrome records metrics ('histograms') about internal activity as you browse the web. These can help diagnose cookie problems.
Go to chrome://histograms and look for the following entries:
- Cookie.SameSiteUnspecifiedEffective: This histogram logs the 'effective' SameSite mode of every cookie that did not specify a SameSite attribute, i.e. what SameSite rules the browser actually applied to it. The '0' bucket corresponds to None, the '1' bucket corresponds to Lax, and the '3' bucket corresponds to Lax and eligible for Lax+POST.
- Cookie.SameSiteNoneIsSecure: This histogram logs whether a SameSite=None cookie was Secure. The '0' bucket means not Secure, and the '1' bucket means Secure.
To debug your own site, you can hit 'Refresh' at the top of the page to clear the previous histogram entries, then check the histogram entries again after reproducing the problem.
For the full descriptions of every histogram, see histograms.xml and enums.xml (very large files!) in the Chromium source tree.
Using a NetLog dump
For this section, we recommend using Chrome 82 or newer, which logs more information than previous versions and may make it easier to identify problematic cookies.
Capture a NetLog dump (a record of all network activity) by following these instructions. Make sure to select “Include cookies and credentials” when you capture the log. (Since such a log may contain sensitive information, such as cookies with login information, use your judgement when sharing it with others.) Use the NetLog viewer to open the captured log.
Click on Events in the sidebar and enter “type:url_request” in the search bar to view all the HTTP(S) requests captured in the log. You can additionally filter by requests with cookies blocked due to SameSite by adding “exclude_samesite” to the search bar.
If you click on each request, you can look for the following things:
- Any COOKIE_INCLUSION_STATUS entry with status 'EXCLUDE_SAMESITE_UNSPECIFIED_TREATED_AS_LAX, WARN_SAMESITE_UNSPECIFIED_CROSS_SITE_CONTEXT' and no other exclusion reasons. This will indicate that the cookie was blocked because of the SameSite-Lax-by-default rules, but would not have been blocked otherwise.
- Statuses with 'WARN_SAMESITE_UNSPECIFIED_LAX_ALLOW_UNSAFE'. This would indicate that the cookie would be expected to be blocked under Lax-by-default, but is instead allowed due to the 2 minute Lax+POST intervention. Such a cookie may not be causing problems now, but will in the future when Lax+POST is deprecated. See 'Testing under Lax+POST' section above for more information.
- Statuses with 'EXCLUDE_SAMESITE_NONE_INSECURE, WARN_SAMESITE_NONE_INSECURE' and no other exclusion reasons. This would indicate that the cookie was blocked because of Cookies-without-SameSite-must-be-Secure, but would not have been blocked otherwise.
- Statuses indicating EXCLUDE_USER_PREFERENCES mean that third-party cookie blocking is enabled, and the blocked cookie was a third-party cookie.
Both request and response cookies are shown here. If you suspect that your server’s Set-Cookie response header is incorrect, you can search for “type:cookie_store” and look for a COOKIE_STORE_COOKIE_ADDED entry, which will list the properties of the cookie, as interpreted by Chrome.
To check whether Chrome considers a request cross-site, you can compare the site_for_cookies property of the request (this represents the top-frame origin) with the URL of the request. If these have the same registrable domain or eTLD+1 (the effective Top Level Domain -- something like .com or .net or .co.uk -- as well as the label immediately to its left) then the request is most likely considered at least Laxly same-site (except in some cases with POST requests) and should attach cookies with SameSite=Lax or cookies defaulted into Lax mode. If they have different registrable domains, or if the site_for_cookies has an empty registrable domain, the request is always considered cross-site. The if the initiator property of the request is either 'not an origin' or also shares the same registrable domain as the site_for_cookies and the request URL, then the request should additionally attach Strict cookies.
The NetLog only covers cookies accessed over the network via HTTP(S) and does not include other methods of cookie access such as document.cookie (JavaScript) or chrome.cookies (extensions). For far more information about debugging using NetLogs, refer to this document.
It was working until M86, now it's broken
There is a known bug with Schemeful Same-Site in which the incorrect issue is displayed. Please see Testing and Debugging Tips for Schemeful Same-Site.
This is fixed in M87.
I found the problematic cookie(s). Now what?
- If the cookie is on a domain you control: You will need to update that cookie by setting SameSite=None; Secure on it. See resources here and here.
- If the cookie is on a third-party domain: You should reach out to the owner of the domain setting that cookie and ask them to update it with SameSite=None; Secure.
Still stuck? Post a question with the “samesite” tag on Stack Overflow, or file a Chrome bug using this template.
Google today launched Chrome 84 for Windows, Mac, Linux, Android, and iOS. Chrome 84 resumes SameSite cookie changes, includes the Web OTP API and Web Animations API, and removes older Transport Layer Security (TLS) versions. You can update to the latest version now using Chrome’s built-in updater or download it directly from google.com/chrome.
With over 1 billion users, Chrome is both a browser and a major platform that web developers must consider. In fact, with Chrome’s regular additions and changes, developers have to stay on top of everything available — as well as what has been deprecated or removed.
First deprecated with Chrome 81 in April, TLS 1.0 and TLS 1.1 have now been completely removed with Chrome 84. This is notable for anyone who manages a website, even if they don’t use Chrome at home or at work. TLS is a cryptographic protocol designed to provide communications security over a computer network — websites use it to secure all communications between their servers and browsers. TLS also succeeds Secure Sockets Layer (SSL) and thus handles the encryption of every HTTPS connection.
Chrome 84 is arriving late. When the coronavirus crisis took hold, Google delayed Chrome 81, skipped Chrome 82 altogether, and moved Chrome 83 up a few weeks. Microsoft followed suit with Edge’s release schedule, consistent with Google’s open source Chromium project, which both Chrome and Edge are based on. Mozilla meanwhile committed to not changing Firefox’s release schedule, which sees a new version every four weeks.
SameSite cookie changes
In May 2016, Chrome 51 introduced the SameSite attribute to allow sites to declare whether cookies should be restricted to a same-site (first-party) context. The hope was this would mitigate cross-site request forgeries (CSRF).
Chrome 80 began enforcing a new secure-by-default cookie classification system, treating cookies that have no declared SameSite value as
SameSite=Lax
cookies. Only cookies set as SameSite=None; Secure
are available in third-party contexts, provided they are being accessed from secure connections. Due to the coronavirus crisis, however, Google paused the SameSite cookie changes, with plans to resume enforcement sometime over the summer. SameSite cookie enforcement has now resumed with a gradual rollout ramping up over the next several weeks for Chrome 80 and newer.The following backward-compatible behaviors are removed as of Chrome 80:
- Disallow defaulting of SameSite attribute to ‘None’: The SameSite attribute now defaults to Lax, meaning your cookies are only available to other sites from top-level navigations. As originally implemented in Chrome, the SameSite attribute defaults to None, which was essentially the Web’s status quo. Cookies have valid cross-site use cases, but if a site owner did not previously want to allow cross-site cookie use, there was no way to declare such an intent or enforce it.
- Value ‘None’ no longer allowed on insecure contexts: Chrome now requires that when the SameSite attribute is set to None, the Secure attribute must also be present. The Secure attribute requires that the attached cookie can only be transmitted over a secure protocol such as HTTPS.
Cross-site cookies that are missing the required settings are effectively blocked.
Web OTP API and Web Animations API
Chrome 84 introduces the Web OTP API (formerly called the SMS Receiver API). This API helps users enter a one-time password (OTP) on a webpage when a specially crafted SMS message is delivered to their Android phone. When verifying the ownership of a phone number, developers typically send an OTP over SMS that must be manually entered by the user (or copied and pasted). The user has to switch to their native SMS app and back to their web app to input the code. The Web OTP API lets developers help users enter the code with one tap.
Chrome 84 also adopts the Web Animations API, which gives developers more control over web animations. These can be used to help users navigate a digital space, remember your app or site, and provide implicit hints around how to use your product. Parts of the API have been around for some time, but this implementation brings greater spec compliance and supports compositing operations, which control how effects are combined and offer many new hooks that enable replaceable events. The API also supports Promises, which allow for animation sequencing and provide greater control over how animations interact with other app features.
Android and iOS
Chrome 84 for Android is rolling out slowly on Google Play. The changelog isn’t available yet — it merely states that “This release includes stability and performance improvements.”
Chrome 84 for iOS meanwhile is out on Apple’s App Store with the usual “stability and performance improvements.” Here is the full changelog:
- You’re now more protected from malware and phishing while browsing with our new Safe Browsing features.
- On iPad, Chrome introduces better mouse and trackpad support.
- You can now share a web page by creating and sharing a QR code. To get started, tap the ‘Share’ icon at the top right.
- You can find your downloads in the downloads folder in Chrome’s menu, or in your device’s Files app.
- You can add nicknames to your payment cards saved in Chrome on your device. Add a nickname when saving a new card or go to Settings > Payment methods > Edit.
Security fixes
Chrome 84 implements 38 security fixes. The following were found by external researchers:
- [$TBD][1103195] Critical CVE-2020-6510: Heap buffer overflow in background fetch. Reported by Leecraso and Guang Gong of 360 Alpha Lab working with 360 BugCloud on 2020-07-08
- [$5000][1074317] High CVE-2020-6511: Side-channel information leakage in content security policy. Reported by Mikhail Oblozhikhin on 2020-04-24
- [$5000][1084820] High CVE-2020-6512: Type Confusion in V8. Reported by nocma, leogan, cheneyxu of WeChat Open Platform Security Team on 2020-05-20
- [$2000][1091404] High CVE-2020-6513: Heap buffer overflow in PDFium. Reported by Aleksandar Nikolic of Cisco Talos on 2020-06-04
- [$TBD][1076703] High CVE-2020-6514: Inappropriate implementation in WebRTC. Reported by Natalie Silvanovich of Google Project Zero on 2020-04-30
- [$TBD][1082755] High CVE-2020-6515: Use after free in tab strip. Reported by DDV_UA on 2020-05-14
- [$TBD][1092449] High CVE-2020-6516: Policy bypass in CORS. Reported by Yongke Wang of Tencent’s Xuanwu Lab (xlab.tencent.com) on 2020-06-08
- [$TBD][1095560] High CVE-2020-6517: Heap buffer overflow in history. Reported by ZeKai Wu (@hellowuzekai) of Tencent Security Xuanwu Lab on 2020-06-16
- [$3000][986051] Medium CVE-2020-6518: Use after free in developer tools. Reported by David Erceg on 2019-07-20
- [$3000][1064676] Medium CVE-2020-6519: Policy bypass in CSP. Reported by Gal Weizman (@WeizmanGal) of PerimeterX on 2020-03-25
- [$1000][1092274] Medium CVE-2020-6520: Heap buffer overflow in Skia. Reported by Zhen Zhou of NSFOCUS Security Team on 2020-06-08
- [$500][1075734] Medium CVE-2020-6521: Side-channel information leakage in autofill. Reported by Xu Lin (University of Illinois at Chicago), Panagiotis Ilia (University of Illinois at Chicago), Jason Polakis (University of Illinois at Chicago) on 2020-04-27
- [$TBD][1052093] Medium CVE-2020-6522: Inappropriate implementation in external protocol handlers. Reported by Eric Lawrence of Microsoft on 2020-02-13
- [$N/A][1080481] Medium CVE-2020-6523: Out of bounds write in Skia. Reported by Liu Wei and Wu Zekai of Tencent Security Xuanwu Lab on 2020-05-08
- [$N/A][1081722] Medium CVE-2020-6524: Heap buffer overflow in WebAudio. Reported by Sung Ta (@Mipu94) of SEFCOM Lab, Arizona State University on 2020-05-12
- [$N/A][1091670] Medium CVE-2020-6525: Heap buffer overflow in Skia. Reported by Zhen Zhou of NSFOCUS Security Team on 2020-06-05
- [$1000][1074340] Low CVE-2020-6526: Inappropriate implementation in iframe sandbox. Reported by Jonathan Kingston on 2020-04-24
- [$500][992698] Low CVE-2020-6527: Insufficient policy enforcement in CSP. Reported by Zhong Zhaochen of andsecurity.cn on 2019-08-10
- [$500][1063690] Low CVE-2020-6528: Incorrect security UI in basic auth. Reported by Rayyan Bijoora on 2020-03-22
- [$N/A][978779] Low CVE-2020-6529: Inappropriate implementation in WebRTC. Reported by kaustubhvats7 on 2019-06-26
- [$N/A][1016278] Low CVE-2020-6530: Out of bounds memory access in developer tools. Reported by myvyang on 2019-10-21
- [$TBD][1042986] Low CVE-2020-6531: Side-channel information leakage in scroll to text. Reported by Jun Kokatsu, Microsoft Browser Vulnerability Research on 2020-01-17
- [$N/A][1069964] Low CVE-2020-6533: Type Confusion in V8. Reported by Avihay Cohen @ SeraphicAlgorithms on 2020-04-11
- [$N/A][1072412] Low CVE-2020-6534: Heap buffer overflow in WebRTC. Reported by Anonymous on 2020-04-20
- [$TBD][1073409] Low CVE-2020-6535: Insufficient data validation in WebUI. Reported by Jun Kokatsu, Microsoft Browser Vulnerability Research on 2020-04-22
- [$TBD][1080934] Low CVE-2020-6536: Incorrect security UI in PWAs. Reported by Zhiyang Zeng of Tencent security platform department on 2020-05-09
- [1105224] Various fixes from internal audits, fuzzing and other initiatives
Google thus spent at least $21,500 in bug bounties for this release. As always, the security fixes alone should be enough incentive for you to upgrade.
Developer features
Chrome offers Origin Trials, which let you try new features and provide feedback on usability, practicality, and effectiveness to the web standards community. Chrome 84 has four new Origin Trials: Cookie Store API, Idle Detection, Origin Isolation, and WebAssembly SIMD. Furthermore, two Origin Trials have graduated and are now enabled by default: Content Indexing API and Wake Lock API based on promises.
As always, Chrome 84 includes the latest V8 JavaScript engine. V8 version 8.4 brings WebAssembly improvements: improved start-up time, better debugging, and the SIMD Origin Trial. There are also new JavaScript features: weak references and finalizers as well as private methods and accessors. Check out the full changelog for more information.
Other developer features in this release include:
- App shortcuts: To improve users’ productivity and facilitate re-engagement with key tasks, Chrome now supports app shortcuts in Android. They allow web developers to provide quick access to a handful of common actions that users need frequently. For sites that are already Progressive Web Apps, creating shortcuts requires only adding items to the web app manifest.
- Autoupgrade Image Mixed Content: “Mixed content” is when an HTTPS page loads content such as scripts or images over insecure HTTP. Previously, mixed images were allowed to load, but the lock icon was removed and, as of Chrome 80, replaced with a Not Secure chip. This was confusing and did not sufficiently discourage developers from loading insecure content that threatens the confidentiality and integrity of users’ data. Starting in Chrome 84, mixed image content will be upgraded to https and images will be blocked if they fail to load after upgrading. Auto upgrading of mixed audio and video content is expected in a future release.
- Blocking Insecure Downloads from Secure (HTTPS) Contexts: Chrome intends to block insecurely delivered downloads initiated from secure contexts (“mixed content downloads”). Once downloaded, a malicious file can circumvent any protections Chrome puts in place. Furthermore, Chrome does not and cannot warn users by downgrading security indicators on secure pages that initiate insecure downloads, as it does not reliably know whether an action will initiate an insecure download until the request is made. User-visible warnings will start in Chrome 84 on desktop, with plans to block insecure downloads completely in Chrome 88. Warnings will not appear in Android until Chrome 85.
- ReportingObserver on Workers: The ReportingObserver API, added in Chrome 69, provides a JavaScript callback function invoked in response to deprecations and browser interventions. The report can be saved, sent to the server, or or handled using arbitrary JavaScript. This feature is designed to give developers greater insight into the operation of their sites on real-world devices. Starting in Chrome 84, this API is exposed on workers.
- Resize Observer: The Resize Observer API was updated to conform to recent specs. ResizeObserverEntry has three new properties,
contentBoxSize
,borderBoxSize
, anddevicePixelContentBoxSize
to provide more detailed information about the DOM feature being observed. This information is returned in an array ofResizeObserverSize
objects, which are also new. - revert Keyword: The revert keyword resets the style of an element to the browser default.
- Unprefixed Appearance CSS Property: An unprefixed version of
-webkit-appearance
is now available in CSS asappearance
. - Unprefixed ruby-position CSS Property: The
ruby-position
property is now supported
in Chrome. This is an unprefixed version of -webkit-ruby-position, which controls the position of a ruby annotation. This property has three possible values:over
,under
, andinter-character
, but Chrome has only implemented the first two. This change creates feature parity with Firefox. - Web Authenticator API: Cross-origin iframe Support: Adds support for web authentication calls from cross-origin iframes if enabled by a feature policy. This brings Chrome in line with the Web Authentication Level Two specification.
For a full rundown of what’s new, check out the Chrome 84 milestone hotlist.
Google should now be back to releasing a new version of its browser every six weeks or so. Chrome 85 will arrive in mid-August.
You can't solo security COVID-19 game security report: Learn the latest attack trends in gaming. Access here