Cookies Will Need a SameSite Setting in February

What changes in February

Chrome 80, due in February, changes how the browser treats cookies: the small pieces of data a site stores in the browser to remember a basket, a login or a half-finished booking.

Today, a cookie with no SameSite setting is sent wherever its site appears, including inside other sites' pages.

From Chrome 80, a cookie with no setting will be treated as first-party only: sent when its own site is the one the visitor is on, and held back when that site is embedded in someone else's page.

Cookies meant to work across sites will have to say so, with SameSite=None, and travel only over secure connections. Google announced the direction in May and set the date in October.

First-party and third-party, in plain terms

When a visitor is on your site, cookies from your own domain are first-party. Your store's basket and your site's login work this way, and in most cases the change leaves them alone.

Many pages also embed tools from other companies: a booking calendar in a frame, a payment form, a chat window, a review widget. Their cookies, inside your page, are third-party.

Those are the cookies affected. If the company behind a tool has not marked them SameSite=None, Chrome will stop sending them, and the tool may forget what the visitor just did.

What can break

• Booking widgets in a frame, losing the chosen time mid-booking.
• Embedded payment forms served from a processor's domain.
• Returns from an off-site payment page, arriving to an empty basket.
• Single sign-on, where one login covers several sites.
• Chat windows that forget the conversation between pages.
• Embedded forms and calendars from outside services.

The third is the least obvious. Some payment pages send the customer back to the store by submitting a form from the processor's site.

Under the new default, the store's own cookie is not sent with that kind of request, so the store may not recognise the customer who has just paid.

Why it is mostly the vendor's job

The cookies belong to the tool, so the fix belongs in the tool's code. The vendor marks the cookies that must work across sites, and serves them only over secure connections.

Your part is to find out whether each vendor has done it, install whatever plugin update or new embed code they release, and test.

Where your own site's code passes visitors to and from other sites, such as a custom payment integration, the developer who built it needs to check it the same way.

The older Apple devices

The fix is not quite as simple as adding one setting everywhere. Browsers on iPhones and iPads still running iOS 12, and Safari on Macs running last year's version of macOS, misread SameSite=None and treat it as the strictest setting.

A vendor that simply adds the setting can fix Chrome and break those visitors instead. Careful vendors recognise the browser and send each one what it understands.

That is worth asking about directly, since plenty of customers have not updated their phones.

What to ask each vendor

Four questions cover it, and they fit in one email.

Is your tool ready for the SameSite change in Chrome 80, and if not, when will it be?

Do we need to do anything on our side, such as installing an update or replacing embed code, and by what date?

Does your fix handle older Apple devices? And if we do nothing, what will customers using Chrome see in February?

Testing before February

Chrome can switch the new behaviour on early. Two settings on its experiments page, chrome://flags, called same-site-by-default-cookies and cookies-without-same-site-must-be-secure, make it behave as Chrome 80 will.

Turn them on, make a booking, run a test payment through a copy of the site, then turn them off again. Chrome's developer tools also print warnings about cookies the change will affect.

It takes half an hour, and turns a vendor's reassurance into something you have seen work.

A worked example

A dance studio with two rooms in a light industrial unit sells most of its drop-in classes through a booking widget embedded from an outside service.

Its web developer turned on Chrome's test settings last week and ran through a booking. The widget loaded and a class could be chosen; the next step said the session had expired.

The widget kept the chosen class in a cookie of its own, set inside the frame with no SameSite setting. Under the new rules, Chrome did not send it back.

The booking service already had updated embed code on its support pages. Swapping it in took ten minutes on a copy of the site, and the test booking went through.

The developer then ran the two other routes where money changes hands, ten-class passes and private lessons, with the same settings on.

What it looks like if something is missed

Problems will arrive as customer complaints rather than error messages, so tell whoever answers the phone what to listen for.

A booking that resets halfway through. A payment taken at the processor while the order on your site still shows as unpaid.

A login that sends people round in a circle. A chat window that greets a returning visitor as a stranger.

If reports like those come mostly from people using Chrome, and start in February, the SameSite change is the first thing to check.

The counter-case

Without embedded tools, logins or online payments, a site is unlikely to be affected at all.

Analytics cookies such as those Universal Analytics sets belong to your own domain, so they are first-party and outside this change. Advertising tags set third-party cookies, but their vendors have the same job; your part is keeping the tags current.

Other browsers are not changing on the same date, either. But Chrome is the most widely used browser, so ask each vendor, apply their updates on a copy, and test before February.

Before February

1. List every embedded tool on your site.
2. Ask each vendor the four questions.
3. Note any update or new embed code.
4. Apply it on a copy of the site first.
5. Turn on Chrome's test settings and book something.
6. Run a test payment through every checkout.
7. Check again the week Chrome 80 arrives.

Step one is the one most businesses cannot do from memory. Booking calendars, payment forms, chat windows and review widgets get added over the years by different people, and nobody keeps the list.

Applying those vendor updates without breaking anything else is covered in clicking update all on a Friday afternoon.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.