After installing the hubspot tracking code, i'm receiving the following warning "A cookie associated with a cross-site resource at http://hs-scripts.com/ was set without the `SameSite` attribute"
I have further checked on this with our product team and I'm able to confirm that the warning will not impact all HubSpot functionality. Any automatic browser handling for cookies without the flag set will force them into a LAX-ish state, which is slightly more permitting than LAX itself and acceptable for the functions HubSpot uses its cookies for.
Let me know if there's any more concerns on this. Happy to help address them.
It’s important to note that HubSpot doesn’t use third party cookies to power the analytics user token we attach to contacts and that this change does not impact any functionality of HubSpot analytics tracking and the HubSpot analytics tracking code and cookies will continue to function correctly.
It is the case that external trackers that use third party cookies may have issues with the flag (e.g. if a website has the Facebook pixel on it), but we don’t have control over the cookies those scripts drop.
I have checked in with our team and we'd first like to clarify that the cookies set by HubSpot analytics scripts do now have the SameSite flag set (and have since February). We would not expect users to be seeing that chrome warning specifically about the js.hs-analytics at this point.
The likely root cause here is that users are seeing warnings referring to either hubspot.com or app.hubspot.com related to HubSpot app cookies (such as login/auth cookies which a user would see on their own HubSpot website if they're logged into HubSpot in that same browser) or possibly cookies related to HubSpot API requests from assets they've embedded on their website.
Having said that, HubSpot analytics passes the values we need as query parameters on requests, so because our tracking doesn't expect the cookie to be present in the header this does not affect our tracking functionality.
Additionally, I'd also like to suggest for you to try loading your website incognito to confirm if you still see those HubSpot warnings or not. If you do not see them in incognito, this can helps confirm that they're related to being logged into HubSpot, and not related to the website itself.
Do let me know if there's any further concerns. I'd be happy to address them 🙂
I have checked in with our team and we'd first like to clarify that the cookies set by HubSpot analytics scripts do now have the SameSite flag set (and have since February). We would not expect users to be seeing that chrome warning specifically about the js.hs-analytics at this point.
The likely root cause here is that users are seeing warnings referring to either hubspot.com or app.hubspot.com related to HubSpot app cookies (such as login/auth cookies which a user would see on their own HubSpot website if they're logged into HubSpot in that same browser) or possibly cookies related to HubSpot API requests from assets they've embedded on their website.
Having said that, HubSpot analytics passes the values we need as query parameters on requests, so because our tracking doesn't expect the cookie to be present in the header this does not affect our tracking functionality.
Additionally, I'd also like to suggest for you to try loading your website incognito to confirm if you still see those HubSpot warnings or not. If you do not see them in incognito, this can helps confirm that they're related to being logged into HubSpot, and not related to the website itself.
Do let me know if there's any further concerns. I'd be happy to address them 🙂
I have further checked on this with our product team and I'm able to confirm that the warning will not impact all HubSpot functionality. Any automatic browser handling for cookies without the flag set will force them into a LAX-ish state, which is slightly more permitting than LAX itself and acceptable for the functions HubSpot uses its cookies for.
Let me know if there's any more concerns on this. Happy to help address them.
I'm not sure this is correct. Apparently Chrome will start blocking cross-site cookies at some point.
"Cookies for cross-site usage must specify SameSite=None; Secure to enable inclusion in third party context."
I'm including the Hubspot tracking code in my company website that is not powered by Hubspot. That tracking code sets a cookie that doesn't include a SameSite attribute. Some browsers will apply a SameSite=Lax in that case. If that cookie as also a cross-site cookie, which this is, it is only a matter of time before browsers block that cookie. My reading is that only if you set SameSite=None and the Secure flag will the browser allow it to be set.
https://web.dev/samesite-cookies-explained/ - Some browsers have a bug where setting SameSite=None is treated as setting it to Strict. So some feature detection would be required. Also setting the Secure flag would require all users of your tracking code to be using https, not a bad requirement, but may break some customers tracking.
Jul 23, 20207:51 AM - bearbeitet Jul 23, 20207:52 AM
Teilnehmer/-in
Hubspot Tracking Code
lösung
Same here, I'm getting some significant warnings and the back-end of a client's WordPress website is crashing every 2 minutes when editing the home page - it would seem because these errors. I have the WP plugin installed too.
I too, am having problems with this - particularly when used with your API. At preent it only affects dev but when Chrome enforce the rule it will break our main site's functionality with Hubspot. Is this being worked on - you simply have to add SameSite=None and Secure to your cookie generation...
I see the same error for all HS cookies on our site originating from the WP plug-in. It appears that this may also be affecting the SEO of the site as I found the issue when running Google's web.dev/measure tool.
I see the same error for all HS cookies on our site originating from the WP plug-in. It appears that this may also be affecting the SEO of the site as I found the issue when running Google's web.dev/measure tool.
Just an update, there's an ongoing discussion with our team on this case and I'll update this thread once we finalize the information. In the meantime, please share any other concerns here. I'd be happy to address them.
Jan 30, 202011:32 AM - bearbeitet Jan 30, 202011:36 AM
Teilnehmer/-in
Hubspot Tracking Code
lösung
So while the LAX-ish state will work fine for HubSpot, it won't work for customers or integrators who use that cookie along with your REST API to identify viewers. If you don't allow the cookie to be read by them, then your REST API which can get a contact by user token (https://developers.hubspot.com/docs/methods/contacts/get_contact_by_utk) will no longer work.
It’s important to note that HubSpot doesn’t use third party cookies to power the analytics user token we attach to contacts and that this change does not impact any functionality of HubSpot analytics tracking and the HubSpot analytics tracking code and cookies will continue to function correctly.
It is the case that external trackers that use third party cookies may have issues with the flag (e.g. if a website has the Facebook pixel on it), but we don’t have control over the cookies those scripts drop.
Just an update here, the warning message is showing because of some updates that Chrome is making. That said, we do not expect the change to have an impact on any HubSpot product functionality as the default way which Chrome is treating the situation is in compliance with what the HubSpot tracking code needs. I hope this helps to clarify!