SameSite Cookie changes
What Chrome 80's SameSite Cookie changes mean...
With roughly two-thirds of the world-wide browser share, Chrome is easily the most popular web-browser in the world, so when they announce that they're changing how cookies work, and that it might break things, that's a big deal.
What are they doing?
For a while now, cookies have supported a property called 'SameSite'. This allows a developer control of when a cookie should be sent to a page, and it's an important step in preventing a security vulnerability called "Cross Site Request Forgery" (CSRF). We won't go into the detail of that - there are lots of articles about this (https://scotthelme.co.uk/csrf-is-dead/) and other related vulnerabilities - but it's a type of attack that has been around for a long time, and developers have had to jump through complicated hoops to prevent. Using "SameSite" cookies with the right settings stops that dead.
Up to Chrome 80, if a developer did not set the SameSite setting on a cookie it defaulted to the least secure setting - "None", which means "send this cookie with requests from any domain". This allowed third-party usage, which is where the security problem comes in and, unfortunately, very few developers used this setting to prevent CSRF. Consequently, Google have decided to default to a more secure setting - "Lax" - to force sites into a more security posture. This is still not the most secure option - but it is much better that "None", and it is less likely to cause problems.
The impact of this is hard to judge - it could break systems, and so Google are doing a soft roll-out, where only some users will have the new default turned on. However, there are some issues that can be predicted:
- Some systems might rely on cross-site cookies for their functionality. These will need to be updated to set a SameSite policy on their cookies. The "None" setting would make cookies work as they have in the past, but now you have to explicitly set this, rather than relying on Chrome's default setting.
- Some development languages don't actually support "None" yet.
- Some other web browsers might not handle a SameSite of "None" as intended - though Chrome, Firefox and Edge all seem on-board.
For example, at the time of writing (February 2020) these changes seem to break Sitecore's App Center login.
It relies on a third-party domain for authentication, and these changes to chrome block cookies from that domain those preventing login (see below). Hopefully that will be fixed, and it would be good if the cookies for apps.sitecore.net were also marked as "Secure"; I can't imagine that they're actually using unencrypted HTTP.
While they're at it, they might prefer responses to https://apps.sitecore.net/ to not advertise the version of IIS, ASP.NET and Microsoft Application Request Routing in their HTTP headers
What will happen in the future?
We expect that Google will continue to move towards a more secure web. In the case of these cookies, we expect that ultimately they will change again to an even more secure default - "Strict" rather than "Lax".
Users will also be given options to simplify removing SameSite=None cookies. This is already an experimental feature in Chrome 80 that can be turned on.
"SameSite=None" cookies allows third party cookies, which can be used for tracking users across many websites, which is a privacy issue. Therefore, we might even see the ability to block Chrome from accepting SameSite=None cookies, though we doubt this will happen quickly (see below).
What's this Third-Party cookie thing?
A third-party cookie is where you are visiting Site A, but it is sending cookies to Site B. If you then visit Site C, which also sends cookies to Site B, then your browsing can be tracked across multiple sites. If you've ever looked at something on one site, and then had adverts on another site show you related ads, that's probably what has just happened.
Thus, third-party cookies aren't just a security issue but are also a privacy issue. Safari already blocks third-party cookies by default, and Firefox is moving to blocking them by default too - but while Chrome has an option to block them, it doesn't by default (yet). A cynic might suggest that this is because Google make money from ad-tracking and ad-services.
Blocking Third-Party cookies may also break systems (https://andrewwburns.com/2019/09/02/sitecore-app-center-login-fails/), but that's probably a necessary evil if privacy is to be improved on the Web. Ultimately it seems likely that they will need to follow Safari and Firefox in blocking third-party cookies by default, but they seem to be trying to find a solution that will both preserve user privacy and advertiser revenue.
References:
