The Cookie Change That Breaks Things Quietly: SameSite Arrives

The privacy changes that get press cycles are the ones with keynotes and acronyms. The one rolling out this month arrived with neither, and it is breaking things anyway, quietly, in exactly the sites that never heard its name.

Chrome 80, deploying gradually across February, enforces a new default for cookies. Cookies without an explicit SameSite attribute are now treated as SameSite=Lax. That means they are no longer sent on most cross-site requests. Cookies that genuinely need cross-site life must now declare it explicitly, as SameSite=None; Secure. The Secure part is mandatory. Cross-site cookies over plain HTTP are simply over.

The change has been announced, scheduled, and re-scheduled by the Chrome team since last May, with developer outreach the whole way. That matters for the pattern this post closes on. The symptoms arriving at help desks this month rarely mention cookies at all. Single-sign-on flows that loop back to the login screen. Embedded content that renders blank. Payment redirects that return to an expired session. The iframed campus map or scheduling tool that stopped working ‘for no reason.’ All of it is the same reason. This post covers the mechanics in brief, the test matrix that finds your exposure, and the pattern that makes this month a rehearsal rather than a fluke.

The mechanics, briefly and honestly

The attribute governs whether a cookie travels with requests that start on a different site than the one that set it. The old default, send cookies everywhere, always, is the plumbing beneath the web’s conveniences. The SSO session recognized across your institution’s domains. The embedded tool that knows who you are. It is also the plumbing beneath its pathologies: cross-site tracking, and the cross-site request forgery attacks that SameSite was originally designed against. The change is a real security improvement, not only a privacy gesture, and that benefit deserves its sentence of credit.

The new default flips the burden. Cross-site cookie behavior is now opt-in, declared in the Set-Cookie header, over HTTPS only. Everything undeclared gets the restricted treatment.

The nuance behind this month’s weirdest bug reports: Lax still permits cookies on top-level navigations. Clicking a link to a site still carries its cookies. Embedded requests (iframes, cross-site POSTs, background calls) do not. That is why breakage is selective and confusing. The vendor’s site works when visited directly, its embedded widget fails, and the help-desk ticket describes a ghost. There is also a temporary two-minute grace window Chrome applies to fresh cookies on some POST flows, which turns certain failures intermittent, the most expensive kind to diagnose. Knowing that much converts most of this month’s mysteries into ordinary tickets.

The test matrix (the useful part)

• Every login flow, especially federated: the SSO round-trips (campus login, social login, enterprise identity) are the highest-impact exposure. Walk each one in a current Chrome. Watch for loops and dropped sessions. Check the identity vendor’s SameSite guidance, which every major provider has published.

• Every payment and form return path: the checkout that hands off to a payment provider and returns. The application flow that crosses a vendor and comes back. Cross-site POST returns are precisely where Lax bites, and where the two-minute window makes failures intermittent. Test with deliberate delays.

• Every embed and iframed tool: re-run the tag census with a cookie lens. The scheduling widgets and the media embeds requiring login. The surveys, the LMS hookups. Anything living in an iframe and expecting a session is on the list.

• The vendor-chasing reality, named: much of this month’s breakage sits in third-party code awaiting third-party patches. That makes the audit partly a procurement exercise. Inventory the affected vendors, cite the Chromium schedule, public since May, and escalate with dates. Your ticket queue should not absorb the cost of their unread announcements.

• Your own Set-Cookie headers, fixed at the source: for first-party code, the fix is a header. Declare SameSite deliberately on every cookie you issue: Lax for the ordinary, None-plus-Secure for the genuinely cross-site, Strict where it fits. An afternoon of work, and the permanent version of the fix.

The pattern, which is the actual story

The recurring pattern is clear: browsers are tightening cross-site behavior on announced schedules as part of ordinary release engineering. ITP began the era, Safari, 2017. SameSite continues it, Chrome, this month. And the endpoint is already public: Chrome announced last month that it intends to phase out third-party cookies entirely within two years. That will make this February look like the gentle rehearsal it is.

The conclusion we want installed permanently: browser-change monitoring is operational practice now, not news-reading. The Chrome release schedule, the WebKit and Firefox release notes, the deprecation trackers. These are infrastructure bulletins for your site, exactly as the platform security lists are. They belong in the same subscribed, staffed, calendared channel.

The teams surprised this month were surprised on schedule. The announcement was public for nine months. The test matrix above was runnable at any point. The difference between the sites that shrugged through February and the ones that spent it in ticket triage was, once again, not talent but attention, institutionalized. The third-party cookie deprecation now has a published horizon. The attention infrastructure you build this quarter is how your organization meets it reading, rather than firefighting.

The short summary

A short finish, because the post’s work is in the matrix. This month’s change is, on the merits, good. A saner cookie default, a real CSRF mitigation, one more step in the privacy trajectory tracked since 2017. The breakage is transitional, concentrated in undeclared plumbing that needed declaring anyway.

The costs land, as usual, on the unmaintained tier and the unread announcements. The remedy is the standing one. Run the matrix this week. Fix your own headers. Chase your vendors with dates. Subscribe the organization to the browser calendars permanently.

The practical conclusion is that browser vendors can and will move the web’s defaults on published schedules. They are visibly emboldened, and the two-year cookie horizon they have now published is the next step, pre-announced. Eleven years of evidence says believe the announcements, and this February added one more data point, quietly, in the ticket queues of everyone who didn’t.