Secure Cross-Site Cookies
In Chrome version 80 (releasing on Feb 4th, 2020) new cookie rules will be enforced. It is likely that you will not be affected by this change, but just to be sure you will want to brush up on what cross site cookies are and what new rules are being taken into effect.
In a nutshell: Cross-Site Cookies.
A cookie is a key value pair along with a couple of attributes. One of those attributes is the domain which is requesting to save it. When the domain that is requesting to save the cookie matches the domain in your browser, this is a same-site cookie. When the two don't match it becomes a cross-site cookie.
There are a lot of good reasons to save cross-site cookies. Such as if you have multiple different apps across different domains that work together in some way. Or if your app lives within some larger ecosystem. For example, embedded Shopify Apps, which live in an iFrame within Shopify's admin dashboard make extensive use of cross-site cookies. So if you have an embedded Shopify app, you are definitely using cross-site cookies.
What are the new rules?
The new rules say that all cookies will default to an attribute of SameSite=Lax. SameSite Lax means that cross-site cookies are sometimes allowed, but only given a certain context. That is, it will not be sent with cross-domain POST requests or when loading the site in a cross-origin frame, but it will be sent when you navigate to the site via a standard top-level link. If they do not meet that context, they will be ignored. So if you want to save a cross-site cookie regardless of context, you now need to add the attribute SameSite=None when you save it. In addition, all SameSite=None cookies must also have the Secure attribute.
So, if previously you just saved a cross-site cookie using the default settings, you now need to ensure that you add the attributes: SameSite=None; Secure to the cookie. This way you can save it.
That's it?
Yes that's it. But there are a couple of lingering problems. The first is that you'll want to make sure that you are actually sending these headers. Most cookie libraries will not let you add the Secure attribute unless your server is actually served over https. This is good practice, but you'll want to make sure you pass the bar. This can be particularly tricky if you are sitting behind a Cloudflare proxy using flexible SSL.
Another catch is that previous versions of Safari actually mis-attribute Same-Site=None and instead set it to a value of Strict instead. So even if you do everything correctly, you will accidentally brick Safari 12 and below along with unpatched versions of Safari 13 (this includes anyone on running OS 10.14 Mojave as well). And you might be thinking "that makes this really hard for me to support all of my customers" and you are right, but unfortunatly that is the world we are living in. Some solutions are to use request headers to decide when to add the attributes to the cookie, or you can save two cookies, and only read data from the one which actually gets saved.
Both of these solutions are monkey patches to get things to work as the world transitions - but I guess that's the price of progress while everyone migrates to the new "Google Chrome 80" defaults.