Infusionsoft Tracking Cookie - SameSite=None (Starting Feb 17, 2020)

Hi Everyone,

Are Infusionsoft’s developers aware of and addressing the new SameSite cookie permission setting that’s coming soon in Chrome?

Coming Issue (Feb 27, 2020)
Without this change Infusionsoft’s cookies are going to be blocked from our website by default. At least that is how I am reading the advisory Chrome developers are giving.

About the Issue

Browser Warning
When visiting a page which tries to set the Infusionsoft tracking cookie, in Google’s Chrome browser (developer tools > Console), I am seeing a warning that Infusionsoft tracking cookies are potentially going to be blocked (starting Feb 27, 2020) when Chrome build 80 (stable) is released.

Previously Chrome allowed a cookie permission of SameSite=Lax
This is the current setting used by Infusionsoft’s tracking code.

Now Chrome is going to require a cookie permission of SameSite-by-default and SameSite=None-requires-Secure

SameSite=None gives unrestricted use of the cookie so it can be set on a third party site, your own website hosting the Infusionsoft code.

Can I ask if Infusionsoft’s developers who maintain the tracking code are aware of the needed change to the script?



Here is what GTMetrix is showing for how Infusionsoft’s cookie is currently set.

Hello Alastair_Greenstreet,
I have exactly the same problem with Chrome (Version 80.0.3987.132)
Embedded forms with javascript aren’t visualized… did you find the solution?
or Keap Team sent you an answer?

Hi Ivan,

Confirming that I had no response on the community forum and haven’t yet taken the issue up directly with Infusionsoft support. Had too much else going on but its definitely an issue.


Hi Aly. It bit me in the butt. They said they were working on it. I submitted a video explanation of the bug, Use-IS-Form-In-LiveO2-Page-ChromeCookieBug, and included reference to your article, Infusionsoft Tracking Cookie - SameSite=None (Starting Feb 17, 2020) - Max Classic - Keap Community.

Adding this here so the next person to complain has more ammo. I repeated your fix suggestion to erode the typical pushback developers use resist fixing stuff.

1 Like

Hi Mark,

Thank you so much for picking up the ball and following up with Infusionsoft Developers on this issue.

I confess to having found the issue but then not had the time and commitment to follow up officially reporting the problem so that is my fault.

Hopefully Infusionsoft are now aware and working the issue, I appreciated the screen cast confirming the problem.

Aly :slight_smile:

Online with IS support now. They asked me to click the link that grants their support team access to our account. The support team reports the same thing they reported 5 months ago. Here is what they said:

Thank you for waiting, upon checking here we currently have a known issue about form not showing in google chrome browser and it is being work on by our developers team.

And I said:
Please emphasize that I reported this issue 5 months ago. I am not happy to have to spend my time diagnosing it again because your development team is unresponsive.
Please connect me to a manager to escalate the issue. 5 months is inappropriate for a bug like this to go unresolved - basically broken forms on a large percentage of all your customers is a painful problem.

Hi @Mark_Squibb,

Looks like they may have fixed the InfusionsoftTrackingCookie to be both Secure & SameSite=None.

However their other two cookies GCLB and JSESSIONID don’t have a SameSite value set but this may not matter as long as the tracking cookie is working for the forms.

Happy days (hopefully).

Aly :slight_smile: