Thanks to EU law changes leading to consent banners on what feels like every website, public awareness of cookies on the web has probably never been higher. Google has introduced two experimental Chrome flags that should make cookies more secure for everyone by default, but could break older websites.
Cookies are, among other things, a way for your browser to let websites know that you’re signed in. In the past, it was easily possible for malicious websites to take advantage of your browser being signed in to a particular other site to access private knowledge or do things you didn’t authorize. Since then, it’s become simple for web developers to manually protect your information by tagging their site’s cookies with “SameSite” and/or “Secure.”
SameSite
When a cookie is tagged with SameSite, Chrome and other browsers know not to use that cookie under certain circumstances when connecting from one website to a completely different one. There are two types of SameSite cookies that web developers can use, depending on their security needs—”Lax” and “Strict.”
“Strict” completely blocks a cookie from being used when connecting from one website to another, and is best used for highly secure websites such as a bank. Conversely, “Lax” is designed to let normal browsing work as expected, only blocking cookies when connecting directly from one website to certain secure aspects of another.
For example, clicking a link to a website you’re logged into should show that you’re already logged in, if the cookie has SameSite set to Lax. However, a malicious page wouldn’t be able to use that same cookie to do something like post a comment on Reddit.
Secure
Over the past few years, Google (along with other companies) has been pushing hard for HTTPS to be the standard way of connecting to the internet. For example, HTTPS websites were previously specially shown to be “secure,” but Google flipped things last year, by showing standard HTTP websites to be “Not secure.”
Similarly, tagging a particular cookie as “Secure” tells Chrome to only use that cookie when making a secure (HTTPS) connection. This is done to ensure that nothing can listen in to your network and make a copy of your cookie for malicious purposes.
The Secure and SameSite tags are incredibly helpful in keeping the web secure, but right now, they rely on the web developer being concerned with security. According to a pair of new flags in chrome://flags, both of which are already live in Chrome Canary, Google is looking at the possibility of all cookies becoming SameSite and Secure cookies by default.
New flags
The first flag, #same-site-by-default-cookies, tells Chrome to treat cookies that do not specify a SameSite setting as though they were set to Lax. This should keep your cookies relatively safe from dangerous misuse without affecting your normal internet browsing habits.
Treat cookies that don’t specify a SameSite attribute as if they were SameSite=Lax. Sites must specify SameSite=None in order to enable third-party usage.
Google is also proposing taking this idea of cookie security by default another step further with a second Chrome flag, #cookies-without-same-site-must-be-secure. When enabled, Chrome will also force cookies that don’t specify SameSite to be “Secure” (unable to be used on insecure connections), if possible. If it’s not possible for that cookie to be secure, because it came from an insecure connection, Chrome will apparently block it altogether.
If enabled, cookies without SameSite restrictions must also be Secure. If a cookie without SameSite restrictions is set without the Secure attribute, it will be treated as Secure (if set from a secure URL), or rejected (if set from an insecure URL). This flag only has an effect if “SameSite by default cookies” is also enabled.
This is a far more aggressive policy, and will almost certainly cause issues for users of websites that have not made the jump to HTTPS yet. Surely there will be some developer backlash, but that’s almost certainly why the policy is behind a flag, to allow Google and other developers to test and see if this is a positive change before potentially making it widespread.
It’s hard to argue against the security benefits that these two policies offer, but there’s definitely some concerns to be shared. As the two flags are only just appearing in Canary, we’re not likely to see them reach stable until Chrome 76 at the earliest. That should give web developers plenty of time to test the flags and raise any potential issues to Google. Depending on the feedback, it’s possible these experimental policies may never reach the average user.
FTC: We use income earning auto affiliate links. More.
Comments