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.

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.

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.

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...

Yes, that is what I am saying.

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.