Google’s Chrome 80 clamps down on cookies and notification spam

Version 80 of the Chrome browser is out with some new features designed to save your security and your sanity.
The latest version of Google’s browser rolled out this Tuesday, 4 February. There are several key changes, but one of the most significant is that it delivers on a promise it made in 2019 about how it handles cookies.
Cookies are the small files websites store in your browser to identify you on future visits. Two kinds of site can request a cookie from your browser. The first is the first-party site that you are visiting, which needs those cookies for things like logging you back in automatically. The second is a third-party site, which the original site might call out to.
There are many reasons for a first-party site to tell a third-party site that you are visiting. Some of them are annoying, like telling advertising companies where you are going online (tracking). Others are more innocuous, such as downloading scripts and fonts from third-party sites to give you a better experience. Either way, if the third-party site doesn’t manage cookies properly, or if another site manages to impersonate a legitimate third-party site, it could introduce security problems. So, Google has introduced tighter third-party cookie controls in Chrome.
The changes pivot around the SameSite tag, which is a draft Internet Engineering Task Force (IETF) standard proposed by Google and Mozilla. Developers can use it to tell browsers that cookies should not be sent with cross-site requests. It helps to eliminate things like cross-site request forgery (CSRF) attacks.
Under the new rules, Chrome 80 will introduce secure-by-default cookie classification using SameSite. If a cookie doesn’t come with an attached SameSite value, then the browser will treat that as though they were tagged SameSite=Lax. That’s the same as forbidding them to be sent to a third-party site.
For a cookie to be sent to a third party, a website developer will have to tag it as SameSite=None; Secure. That means it can only be sent to sites using HTTPS, which is the more secure, encrypted version of the Hypertext Transfer Protocol that web servers use to send a browser their web page data.

This won’t happen all at once. Google will roll it out to a small population of Chrome 80 users later in February, gradually increasing its coverage over time. If all the rows show up green on this page, then you’re in that group.
Other changes in Chrome 80 include an alteration in the way that it handles website notifications. These are the small windows that pop up in your browser with things like news and messages. In existing versions of Chrome, you have to give a site express permission before it sends you notifications, but even that initial permission request can be annoying. A lot of sites pop them up as soon as you load them, and malicious sites can also use them for scams and malware.
Last month, the Chromium blog announced that Chrome 80 will include a new, quieter notification permission interface. Instead of a box that blares at you, interrupting your flow, you’ll see a polite little bell icon in the address bar to warn you that notifications are blocked. If you click the bell, you’ll still be able to see the content.
It sounds like Chrome will learn from your behaviour when offering this feature. Typically, you’ll have to opt-in manually using Chrome’s settings (go to Settings > Site Settings > Notifications), but the browser will also turn it on automatically if it sees you blocking notification permission requests as a matter of course. It will also enable it for sites that have very low opt-in rates.
Chrome 80 also sees some changes in the way that the browser handles HTTPS requests. The problem is many pages using HTTPS still load some of the content they contain using insecure HTTP. This is called mixed content and it’s a particular problem for images, audio, and video, Google has said. It’s all very well loading a page securely, but if it loads an insecure image that compromises your browser, you may as well not have bothered with HTTPS at all.
The company moved towards blocking all mixed content by default in Chrome 79, but it’s doing it in stages. In Chrome 80, mixed audio and video resources will be upgraded automatically to HTTPS. If they can’t load using that protocol, the browser will block them. Mixed images will still load, but they will prompt a “Not Secure” icon in the omnibox (that’s the address bar, to you and me).

---

Latest Naked Security podcast