This FAQ aims to answer common questions regarding the email that was sent out to our customers in December 2019 regarding changes to the Chrome browser that might affect how your application uses and handles cookies. If you do not find your answer here, please contact firstname.lastname@example.org.
Q: What changes will be made to cookie handling?
A: Currently, it is possible to issue first-party cookies, or cookies that are issued by the domain that’s being displayed in the end-user’s URL bar, without a SameSite value (either
SameSite=Strict). To reduce the potential for attacks, Chrome will be introducing a new value,
SameSite=None, to make it explicit that a cookie is meant for cross-site use. Cookies without a SameSite value will be treated as
SameSite=Lax cookies. For further information, visit https://blog.chromium.org/2019/10/developers-get-ready-for-new.html.
Q: Can you point me to some resources on the SameSite change?
A: Here are some resources for getting up to speed on the upcoming change:
- Chromium blog post about the upcoming change: https://blog.chromium.org/2019/10/developers-get-ready-for-new.html
- Chromium SameSite status page (contains release schedule): https://www.chromium.org/updates/same-site
- SameSite cookies explained: https://web.dev/samesite-cookies-explained/
- SameSite cookie recipes (how to prepare for the change): https://web.dev/samesite-cookie-recipes/
- Clients (browsers) that do not handle
- Some .Net resources: https://devblogs.microsoft.com/aspnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/ and https://docs.microsoft.com/en-us/dotnet/core/compatibility/aspnetcore
Q: When will the changes come into effect?
A: The SameSite changes will gradually be rolled out starting February 17th, 2020. The initial Chrome 80 release, scheduled February 4th, will not contain the SameSite changes. Google originally planned to introduce the change in the initial Chrome 80 release, but later changed to a more gradual and controlled roll-out (see https://www.chromium.org/updates/same-site for an up-to-date release schedule).
Q: Will my application be affected?
A: Signicat will ensure that services provided by Signicat will work as before. You will need to implement any necessary changes to cookies that are issued by your own application and do not currently have a SameSite value.
Q: I use a subdomain, how am I affected?
A: Subdomains (https://developer.signicat.com/documentation/other/signicat-subdomain/) will generally make the cookies a first-party cookie, but if you do redirects to any other domains, then the Chrome change might affect you.
Q: Do I need to take any action?
A: If you rely on cookies (i.e. a session cookie) that’s not first-party, you will need to do an analysis on how this might affect you and make appropriate changes if needed.
Q: How will Signicat handle the SameSite change for Signicat’s cookies?
A: Signicat will use an approach that includes setting both the new and old style cookies (explained at https://web.dev/samesite-cookie-recipes/) to support the upcoming SameSite change for the cookies that we create. We found this to be the most robust solution. It will however leave some warnings in the developer console for the fallback/legacy cookies (which do not have
SameSite=None set), but we found this to be an acceptable trade-off.
Q: Can I already now, in Chrome 79, test if my integration with Signicat will work in Chrome 80?
A: By inspecting the developer console in Chrome 79 after a full authentication or signature flow, you should be able to see if any warnings are reported for your cookies. This will give an indication on whether you will need to do anything with your cookies. You can test the behavior that will be enabled in Chrome 80 by enabling “SameSite by default cookies” and “Cookies without SameSite must be secure” in chrome://flags.