4 ms·

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 requi

by hirsin 7y ago

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.

andrei_says_ 7y ago
Precisely this. The 800 pound gorilla changing the rules on everyone is very bad despite short term outcome.
- hirsin 7y ago
  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.
  - tptacek 7y ago
    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.
    - TeMPOraL 7y ago
      The horse is supposed to drag the cart where the coachman tells it to, and not where it pleases.
      - tptacek 7y ago
        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.
        parley 7y ago
        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.
        tptacek 7y ago
        Yes, that is what I am saying.
        tialaramex 7y ago
        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...
        TeMPOraL 7y ago
        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.
      - kerkeslager 7y ago
        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.
    - hirsin 7y ago
      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.
      - tptacek 7y ago
        What's your community and how is default SameSite=lax costing it so much?
        hirsin 7y ago
        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.
  - tylerl 7y ago
    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.
    - hirsin 7y ago
      That is not how specs work.
fortran77 7y ago
I think they've _both_ done a "heckuva job"
foresto 7y ago
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.
- joshuamorton 7y ago
  What's your definition of "working"? To some people, a system with a security vulnerability isn't "working".
  - foresto 7y ago
    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.
    - tptacek 7y ago
      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".
    - joshuamorton 7y ago
      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.
tylerl 7y ago
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.
- hirsin 7y ago
  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.
  - lstamour 7y ago
    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...

by hirsin 7y ago

andrei_says_ 7y ago

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

hirsin 7y ago
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.
- tptacek 7y ago
  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.
  - TeMPOraL 7y ago
    The horse is supposed to drag the cart where the coachman tells it to, and not where it pleases.
    - tptacek 7y ago
      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.
      - parley 7y ago
        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.
        tptacek 7y ago
        Yes, that is what I am saying.
        tialaramex 7y ago
        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...
      - TeMPOraL 7y ago
        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.
    - kerkeslager 7y ago
      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.
  - hirsin 7y ago
    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.
    - tptacek 7y ago
      What's your community and how is default SameSite=lax costing it so much?
      - hirsin 7y ago
        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.
- tylerl 7y ago
  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.
  - hirsin 7y ago
    That is not how specs work.

fortran77 7y ago

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

foresto 7y ago

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.

joshuamorton 7y ago
What's your definition of "working"? To some people, a system with a security vulnerability isn't "working".
- foresto 7y ago
  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.
  - tptacek 7y ago
    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".
  - joshuamorton 7y ago
    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.

tylerl 7y ago

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.

hirsin 7y ago
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.
- lstamour 7y ago
  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...