The developer world continues its tenuous courtship with the Google-Plex behemoth in Mountain View. Their pseudo-monopoly in browser and search drive us crazy at times. Call us frenemies … call it a love/hate relationship … but when Google Updates call in the middle of the night, we all come a’running because if our websites are not found and displayed properly online things get bad.
There are recent July 4th updates to the Chrome browser that can affect just about every website on the internet. We are tracking these to ensure that our customers are well-prepared for updates and adapted to the changes as they occur. Here’s what you need to know.
Google Chrome Release 84 — Browser Update of July 14, 2020
Why Chrome 84 Matters
Google continues to dominate the browser market. According to StatCounter, Google Chrome accounts for ~65.5% market share. Safari clings to a ~17% share, which means that these two account for more than 82% of all internet traffic. They track seven other browsers as carving up the remaining table scraps with a couple of points each. More importantly, Google uses this dominant position to steer the market. If a feature or restriction is released in Chrome, it’s a fair bet that it exists in all the others or is on way.
Yadda, yadda, yadda … it matters.
Even though it has been twelve days since the release came out, we’ve not seen a user-friendly summary from Google yet. So, we are listing the things that we and others in the community have documented or noticed.
Google Chrome 84 Patches Security Vulnerabilities
It’s been more than 60 days since a Chrome release. In that window, Google paid out more than $20k in bounties to attentive hackers and developers who identified existing vulnerabilities and potential exploits. In total, there were 38 patches, one of them was Critical and seven were High. You can read a complete list of the security updates here in the ChromeReleases section of the technical GoogleBlog.
So, since we are a security-first organization, we strongly recommend that you Update Chrome on all your devices — mobile, desktop, and servers.
Chrome Blocking Sites The Don’t Have TLS 1.2 Enabled
Google developers have been promising this for over a year. We need a quick history lesson ….
SSL (Secure Socket layer) was the original gangsta of data-packet security. Nearly all browsers are insisting on SSL-implementation as a minimum as of about three years ago (we wrote about it at the time). But even then, SSL was old-school. TLS updated and surpassed SSL in 1999. That requirement was the first step. Everyone knew that the writing was on the wall and TLS would soon cease to be a “recommendation” and become a “requirement” — as in, “We’ll make you a deal you can’t refuse.” That day appears to have arrived.
Reports are that the current release of Google Chrome is blocking/warning sites that do not have TLS 1.2 implemented. If you have noticed a drop in website traffic over the last month, it could be your ad campaign or social media strategy. But the first place to look is in the code. Ensure that TLS 1.2 is implemented everywhere and on cross-linked sites and resources.
Pro-Tip: While you’re at it, consider saving some time and roll all the way up to TLS 1.3 now if practical to do so. It’s a stable release, it’s good security policy, and you know that more stringent security requirements will come eventually. Your “future self” will thank you.
Google Chrome 84 Deploys “SameSite” for Cookies
Google promised to deploy SameSite back in the Chrome 80 release at the beginning of the year. But, there were concerns and delays and a few legitimate conflicts and then COVID happened. Anyway … SameSite is now available in the current Chrome 84 release.
In a nutshell, SameSite is a way to let browser users have a little control over how much tracking is done across the internet. It was pushed as a product differentiator by Mozilla and Microsoft Edge who both had it first. Chrome users can now set their browsers to STRICT, LAX, or NONE. Simply stated, LAX will allow the tracking of third-party cookies and STRICT will limit cookie tracking to first-party sites. But what does that mean?
A first-party cookie means that the browser recognizes the cookies of a site that the user is currently visiting to make the page load faster in the future and remember user preferences, that kind of thing. So far so good … no problema. But a third-party cookie is where a website deploys or recognizes a cookie from another website. This can be quite legitimate. For example, if you embed a YouTube video on your website and there is a “Play Later” button, that sets a third-party cookie so that the user can see the video queued up in their normal YouTube feed.
Third-party cookies are also how retargeting ads work. You set a cookie when a user is on your page. Then, when they are surfing the web, you can cause sites that use ad networks to display your ads because the site and ad network recognize your cookie. There are also certain payment gateways that use third-party cookies for eCommerce transactions.
But there are also third-party cookies that are used to track users across websites in general. And that is something that users are beginning to get sensitive about. SameSite lets users have some control over that. It’s not clear how many users will use the new setting. But if you use embedded videos, external payment gateways, deploy retargeting ads, or utilize other services that make use of third-party cookies you should test your systems for potential impacts.
More Info to Come
As we previously mentioned, as we write this Google has not released an article discussing all the changes. We look forward to that and will let you know if additional significant changes have been deployed. If you are aware of other significant changes, let us know. If you need help determining the impact to your website or application, we’re always happy to help.