Hacker News Reader

Comment by hirsin | Hacker News Reader

No. They have a bug in their implementation of the spec, but Chrome is going off spec here, and dropping breaking changes into the ecosystem in a way that requires developers to UA sniff.

The Safari bug is annoying today, but ultimately didn't impact anyone that was spec compliant. Chrome does impact people who are spec compliant.

View on HN

Precisely this. The 800 pound gorilla changing the rules on everyone is very bad despite short term outcome.

Yup. This is a good change and should have been the default from the start. But it wasn't, so you need to play by the rules - standard first, let the framework developers at least implement this so it doesn't require header hacks, and then release it.

Or: they don't need to play by "the rules", because the horse drags the cart and not the other way around. Sometimes major vendor fiat decisions are abusive, and sometimes they're productive; you have to judge them on their merits, and not by their compliance to a phony law of standardization.

The horse is supposed to drag the cart where the coachman tells it to, and not where it pleases.

That's just not a valid argument. Standards groups don't tell developers what to build. Developers tell standards groups what they have built, when they want what they're building to be interoperable.

The notion that vendors are beholden to standards groups is a real problem. It's what got us stuff like Heartbleed.

Do you mean to say that you think that the OpenSSL project feeling obliged to implement the heartbeat extension created by a standards body is significantly more to blame for causing Heartbleed than the (understandable) causes for the general quality of the OpenSSL project code base (like lack of funding, etc)?

EDIT: Clarification.

Yes, that is what I am saying.

OpenSSL is one of a number of projects (this is maybe more prevalent in Free Software but it's hard to tell) which takes the approach of a hoarder rather than curator, it has got better, but that's definitely how it got to where it was when Heartbleed happened.

In these projects rather than try to solve some particular problem or group of problems and use standards on the path to that solution, the project just throws together whatever happened to attract somebody's interest in a standard into a big heap of cool toys without rhyme or reason.

I think we actually could have blindly got lucky with Heartbleed, it could easily have been the case that to make this extension work you needed to add 40 lines of custom code to every program even though it would always be identical boilerplate code. After all it took them years to add a sane API for "Just check the bloody hostname in the certificate matches". But, that isn't how it worked out.

If you compare Python's "batteries included" philosophy, OpenSSL and a few other libraries take something closer to: "I just keep everything in this old cardboard box, try looking in there?". And sure enough there are batteries, although they seem to be covered in a sweet-smelling sticky substance, there is also a broken Gamecube, one cufflink with a brand logo you don't recognise, a chocolate bar dated 1986, a PS/2 to USB adaptor, a C60 cassette, two dried-out PostIt notes, one sock, a 40cm USB cable with a mini-B connector, and the spare fuses from a 2005 Ford Focus...

The problem here is that Google at this point is essentially forcing everyone to do what they want. Maybe it's for the better this time, but often enough it's for the worse, and I don't trust their intentions.

Okay, but this metaphor is completely nonsensical when applied to standards, because if you plug the parts of reality into the parts of the metaphor, the horse is part of the coachman.

Developers determine standards, and it would be pointless to make standards any other way because the standards wouldn't ever be implemented if there were no developers who wanted to implement them.

OK, fine - this will cost just my developer community alone 10-50 million dollars in rework. Maybe that's acceptable to the Chrome team, but I'm the one sending that mail to a hundred thousand developers, not them. So I weigh it differently.

What's your community and how is default SameSite=lax costing it so much?

Give or take 2 of the 5 largest OIDC providers. This change broke form_post in OIDC, so every app using it (low 5 digit count) needs to update and redeploy.

This isn't Chrome going against the spec. This is the spec's author (who happens to work on Chrome) changing the spec.

Since the spec is still in draft, changes are expected. This isn't even the first change, we're already on version 3. And this version expires next month, so we're literally, explicitly, due for a new revision.

That is not how specs work.

Your argument is bad and you should feel bad. The status quo is stupid.

So the Chrome team wants to make their own users safer. Good for them. In the absurdly stupid scenario where sites are making cookie-mediated blind cross-site POST requests, they'll have to come up with a better interaction model. Once we figure out who these hypothetical idiots are and whether they exist at all, we can all shed a tear for them and the extra 7 hours of work they'll have to do in order to adjust. But in the mean time, all Chrome users become immediately immune to an entire class of vulnerabilities. As far as trade-offs go, I'd take it. Good on you, Chrome team.

Sure, site owners can't just relax yet and call the problem transparently solved; legacy browsers will continue to exist for years. But that's hardly a reason not to make progress.

The spec compliance argument is utter nonsense. You know what else broke the spec? Ad block. No-script. Popup blocking. Private browsing. Third-party cookie blocking. Pretty much everything that has made any particular browser "good" has been a deviation from the spec.

Nah. You have a blind spot because I'm guessing you're not responsible for a developer ecosystem, otherwise you'd not spout off with absolutes, especially when you're just wrong.

These "hypothetical idiots", in my case, are developers who used the off the shelf libraries and SDKs built to spec, that rely on 3rd party cookies for things like logging in users and logging them out.

You know the number one use case for 3rd party cookies in that scenario? Ensuring no one has injected or otherwise fraudulently initiated an auth request when the IDP posts back to your site. That forgery check is now broken. In the words of a wise gent from a couple years back, congrats, you played yourself.

Want to set samesite in your language of choice? Enjoy setting headers manually now and praying, because even if your framework does have samesite support it's probably going to emit nothing if you choose none, because that's the spec.

Actually most of the JS cookie libraries I’ve used have an explicit “None” string that’s separate from a null or disabled setting. And the spec is carefully written such that it doesn’t actually say whether the default is None or Lax, it’s now unspecified...

Someone once shared a mantra that later became one of my basic design principles, especially when introducing changes to things that people already use: "Don't break working systems."

I wish more developers understood why this is important.

What's your definition of "working"? To some people, a system with a security vulnerability isn't "working".

I believe the phrase "things that people already use" answers your question.

> To some people, a system with a security vulnerability isn't "working".

Yes, we have seen that argument more than a few times before, usually from someone justifying their personal agenda without regard for its impact on other people, despite the availability of less disruptive options. Ego is a funny thing.

Obviously, there are times when lack of immediate action would have dire consequences, but I think it would be disingenuous to claim that was the norm, or to claim that this Chrome change is an example.

It's funny, because for people who care a lot about security engineering, "my system should continue running as it is even if it exposes its users to preventable security threats" also sounds pretty "egotistical".

It really doesn't. Either the system is working, or it isn't. People might be using it, but people use all sorts of broken systems.

It is indeed worth weighing the cost of making a breaking change, but given that it happens all the time in all sorts of projects, it's clear that only very few projects subscribe to your notion that breaking users are an absolute sin.

Even Linux has broken userspace programs when fixing bugs. It's only happened a few times, but it happens.

I think they've _both_ done a "heckuva job"

Reply on news.ycombinator.com