Comment by ReidZB | Hacker News Reader

Comment by ReidZB | Hacker News Reader

I work for a company whose endpoints end up being embedded in iframes in external systems, and this change is currently causing no small deal of heartburn for several folks here.

I really don't like that the Powers That Be have decided to make this change, for many reasons:

1. Changing the default behavior of a thing on the 'net that's been around for so long. Like the article says, I can't wait to see the various and sundry things that are all broken as a result.

2. To set SameSite=None and get back to the old behavior (more on this in a second), you need to do... user agent sniffing, because some browsers (as the sibling comment by swang says) will choke on None and fall back to Strict. Great, so sometimes set SameSite=None, sometimes don't set it or else things will break. eye roll

3. As the article says, SameSite=None is only allowed on Secure cookies, which means you actually can't get back to the old behavior. Now, my company has been telling people for years to stop using HTTP (and customers have to contact support to even get HTTP support enabled). However, there are a few enterprise-y holdouts. In several cases, we've had to go be the bearers of bad news. Albeit, there is an undercurrent of glee in finally forcing them to stop being bad stewards of data (assuming they don't just enterprise-policy it away), but still, from a business perspective it's very frustrating.

So, in sum, it'll break stuff that's not updated (my guess: a lot of stuff), setting SameSite=None requires a user-agent-sniffing hack, and even setting SameSite=None is not a complete solution if you're using HTTP for some reason.

And for what, exactly? This would've been nice in 1995, but it's a bit late now. Though, I guess maybe twenty years from now we can rip out (or stop writing) some anti-CSRF code or something.

You don't fix security problems with the Same Origin Policy because you're trying to free up some anti-CSRF code to make developer lives easier. You do it because mistakes with that anti-CSRF code result in vulnerabilities, which harm users, who are an externality both to developers and standards authors. And those mistakes happen all the time.

The SameSite change we're talking about decisively mitigates most CSRF vulnerabilities. Once widely deployed, it probably kills the bug class, turning it into another bug bounty eye-roller like ClickJacking, rather than what it is now: a bug that is routinely exploitable on significant sites. It is more than worth it; it's one of the smartest things the browser vendors have done in awhile.

I like making the internet less dangerous to handle, so to speak, but there are always trade-offs, and I'm not sure that changing the default brings enough benefit to warrant all the pain.

To me, it seems like it would've been better to use this energy to push the community into opting into SameSite={Lax,Strict} by default (make it a 'best practices' thing). Get it added to automated security tooling, make the browser console print messages for cookies missing SameSite, etc.

Albeit, it is much harder to reach all the web devs in the world, and so some sites may not opt into SameSite and be bitten by CSRF, but that is in line with e.g. X-Frame-Options / Content-Security-Policy. It's not ideal, but it preserves backwards compatibility, which is a thing I value very, very highly.

You're not wrong, the universe with SameSite available is safer than the ones without it. The migration is just frustratingly painful for those of us stuck between slow framework updates, unsupported browsers, and customers who are slow to upgrade our software. And for those of us who have csrf protections, it's effort spent just to maintain the status quo ante.

> turning it into another bug bounty eye-roller like ClickJacking

When did clickjacking get mitigated by default by browsers? As far as I know it’s still up to websites to prevent framing explicitly.

I'm not saying that CJ has been mitigated by default the way CSRF is poised to be, but rather that it's very rarely exploitable, which is soon to be the case for CSRF as well.

20 years is too pessimistic. It was nearly accurate exactly once, which is where IE6 remained dominant for nearly a decade and a half. As far as anyone can tell, there will probably not be another case where a single outdated version of a browser contains a significant part of the marketshare. Most folks are now using browsers that update automatically, be it Edge, Safari, Chrome, Firefox or even numerous niche browsers.

There of course remain some demographics where outdated browsers live on. Like I'm sure the last version of Chrome that works on XP has some marketshare in China.

The worst case I can really think of is older Android, but let's at least keep in mind that Android has only been in people's hands for a decade, and practically speaking most developers are not very concerned with supporting Android Browser from really old Android releases. IIRC, Cloudflare's free tier already doesn't work with Android Browser from 2.2 because at that point it didn't support SNI. Not to mention, Android Browser marketshare is quite tiny at this point, as I believe Chrome or Samsung Browser is usually the default browser on modern Android handsets.

I would guess as long as this move goes off without a hitch and isn't reverted it will likely be the safe reality in under 5 years. My guess is not particularly special, but I mean, the internet is already unusable on really old browsers. For better or worse, the world we live in doesn't have much tolerance for older software versions. Sometimes this is for pretty good reasons (such as improving cryptography standards.)

I will admit I have a strong aversion to breaking browser support for anyone pretty much, but the security of 95% of users is worth forcing 5% of users to update their damn software. It's unfortunate that the situation can't be a bit more backwards compatible, but I think that's just how things go with certain hard problems. There's never not going to be some compromise, and it doesn't seem likely any time in the future will be particularly better than right now.

I agree on the dislike for the change, although it's not a big hassle for us at work.

The bigger headache for me is updating side-projects: I get little enough time to work on them and when I do have time I want to be doing interesting stuff, not jumping through bureaucratic hoops.

It's just no longer the case that you can put anything on the web, apart from basic static content, and have any hope it'll still "just work" in 5 years time because a bunch of do-gooders and busybodies at Google, Mozilla, Apple and the like are constantly fettling behaviour that's been standard for years with sometimes debatable justification.

This is one issue. Others I've had to deal with in the past 2 - 3 years that spring immediately to mind: blocking access to audio context, blocking access to device orientation[1], (lack of) reliable full screen support on iOS.

It gets tedious.

[1] This one caught me completely off guard: I'd had no idea any change was being made here until some time after it had happened.

Backwards compatibility at all costs is a main driver of insecurity.

This change is a good example where the security benefits clearly outweigh the downsides.

We're talking about changing a default behaviour that will affect literally every website that uses cookies. That's a trade-off where I'm not sure the benefits do clearly outweigh the downsides.

No, that's not true. The new default behavior doesn't change the way cookies on ordinary websites work at all; that's why the change was viable. It affects third-party cookies.

Does it affect all iframed websites (e.g., game sites iframed by an aggregator like Kongregate)?

If they use an actual iframe, most likely not. But if they're making Cross-origin requests from JS, probably.

The article discusses iframe behaviour

Reply on news.ycombinator.com