Update Marketo cookie setting to not break in Chrome 80

[Casey_Grimes]

Upcoming changes to Chromium are enforcing better policies around using Secure and SameSite flags in cookies. Unfortunately, this conflicts with the way Marketo writes cookies today and could potentially cause major issues for Marketo customers once this is rolled out—Microsoft and Mozilla are also planning to treat cookie flags differently around the same time.

Could cookie writing please be updated at a minimum to have the Secure flag set (and preferably explicitly declare SameSite=None when appropriate on third-party values and Lax on first-party)? Otherwise, this could lead to headaches. Getting it prioritized now will ensure the transition is seamless for Marketo customers.

[Crystal_Pacheco]

Courtney Grimes‌ did you experience any issues with people not getting cookied through Marketo? Is this issue relevant to Marketo if the munchkin code is on an external website? Or is it also an issue with Marketo landing pages?The SameSite warning issue is also occurring from Google Tag Manager and most likely Google Analytics as well.

[SanfordWhiteman]

The standard public release of Chrome (78) doesn't have the measure implemented yet. The beta (79) has it implemented in A/B mode. Dev + early  (Canary) channels have it implemented in full. So regular users are not as of today impacted.

However, what Courtney's looking for isn't entirely possible. You can't set the secure flag on an insecure site, ergo you can't set secure;samesite=none on an insecure site.

[Casey_Grimes]

My understanding (and correct me if I'm wrong) is that it is only the domain the cookie is setting from when third-party that needs to be secure (e.g., if you go to an HTTP-only site but the third party is HTTPS, you can still set a secure flag on the cookie)—strictly speaking, the secure flag only provides confidentiality and not integrity. That would only put the onus on marketo.net to be secure, and it already is.

What you're implying—that there's no way to implement secure;SameSite=none while being insecure—would be a much larger implication of "oh hey everyone using any sort of adtech must have TLS by Chrome 80 for first-party or it'll break", and I just don't see that as the case here.

[SanfordWhiteman]

Try it yourself: you can't set a secure flag for a cookie on an insecure page.

[SanfordWhiteman]

Just to be sure, I tested this in all modern (and even not modern) browsers. My test page used JS (as does Munchkin) to set an insecure cookie (TestInsecure) and a secure cookie (TestSecure).

The results are unanimous: it isn't possible to set a secure cookie from an insecure main document, while it is always possible if the main document is secure. Note the cookie is written from an external script that's loaded over https: -- exactly as with the Munchkin lib -- and the protocol that happened to load that script doesn't matter.

You can think of the browser's cookie store as inheriting the security of the main document. It makes sense that I can't say "only set this cookie in a secure environment" when the page itself, and thus all of its assets, was subject to interception.

.