6 ms·

It gets better: the linked Chrome feature "Cookies default to SameSite=Lax" mentions a bug in Safari (fixed in a not-yet-released version) that causes cookies w

It gets better: the linked Chrome feature "Cookies default to SameSite=Lax" mentions a bug in Safari (fixed in a not-yet-released version) that causes cookies with "SameSite=None" to not be sent in cross-site requests. So when Chrome 80 comes out, your options for setting cross-site cookies will look like: * send nothing, and break in Chrome 80+ because of the new default * send "SameSite=None", and break on any Safari besides the latest because of the bug * send anything else, and break because that's what SameSite does Heckuva job, Chrome team.

tptacek 7y ago
Don't you mean "heckuva job, Safari team"?
- 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...
  - 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...
sieabahlpark 7y ago
News flash, absolutely no one care about chrome breaking the web because Google owns the web. Literally, they're the biggest ad agency, biggest captcha provider (v3 will be on every page if they get their way), biggest browser. Google can and will do whatever they want and there is no amount of complaining that will actually change their mind. Just lookup how they hamfisted their autoplay into the ecosystem despite breaking every website. YouTube is whitelisted to not need to follow their autoplay guidelines though :)
- gridlockd 7y ago
  > News flash, absolutely no one care about chrome breaking the web because Google owns the web. No they don't. Eight out of the Top Ten websites are not owned by Google. If Chrome became the browser that broke major websites all the time, people would switch really quick. > Just lookup how they hamfisted their autoplay into the ecosystem despite breaking every website. It didn't break "every website", because most websites never had any obnoxious autoplaying media to begin with. Popup Blockers also broke "every website" that had the guts to open pop ups, most of which were not solicited by the user. In either case, strong user preference was behind these changes. It didn't need some consortium of conflicting interests to standardize acceptable website behavior. If users didn't matter and it was all about Google's interests, you wouldn't have adblockers in Chrome. You wouldn't be able to watch Youtube flawlessly without ever seeing any ads.
devinl 7y ago
ITP 2.1 also already says it will block cookies of this type if it matches Safari's completely non-transparent ML model for "tracking cookies". Also Chrome pushed back the release date of this new default from end of August 2019 to February 2020 and the bug has been "fixed in a non-yet released version" of Safari since early June (safari is really slow to release security patches).
kerkeslager 7y ago
As a user, when I visit a site, I never invited some third party to run their code on my computer, and I certainly don't want some third party making requests to the server on my behalf. So screw websites that depend on this bug.
- olalonde 7y ago
  Just to clarify, CSRF is when a website you visit makes requests on your behalf to a third party (which you have visited/logged into). The third party is also a "victim" of the attack. > I never invited some third party to run their code on my computer This can be achieved by disabling JavaScript (e.g. NoScript extension). As far as I know, there's no extension that can entirely prevent a website from loading resources from other another domain name. If there is, I imagine it would cause a lot of websites to lack styling, images/videos not loading, etc.
  - mehhh 7y ago
    uMatrix can be used to block 3rd party resources from loading (like Facebook and Google, usually blockable with no ill effects).
  - kerkeslager 7y ago
    Yes, I knew this, and I said the wrong thing anyway, and I am sorry. I didn't think through what I was saying clearly. My intent was more of an "Old Man Yells At Cloud" thing; I was just kvetching because the internet isn't as user-focused as it could be. Calling a bunch of resources from all over the place is a user-hostile behavior, and I'm generally unsympathetic when sites break because browsers narrow the range of user-hostile behaviors they support.
cookiecaper 7y ago
I'm sure this is secretly considered a feature by at least some people inside of Google. Safari's share of the market is already quite small and most MacOS users are able to figure out how to install Chrome (most do so already). If sites magically stop working in Safari, it helps to drive more of that already-weak marketshare to the "just works [because we broke it]" alternative of Chrome.
- yyyk 7y ago
  All iOS browsers have to use Safari's engine, so users who download Chrome gain nothing in this regard. The only choices available are either to ignore iOS or support Safari.
slowmovintarget 7y ago
At home I've switched back to Firefox. Seems like I need to complete that transition at work to continue enjoying things like ad blocking and functional sites. In fact, maybe sites should start recommending something like that. (Microsoft's wallet sense must be twinging.)
- mikepurvis 7y ago
  I switched back to Firefox recently as well— the containers plugin has me completely won over. It takes a while to get in the groove of it, but surfing the internet and not being logged into Google and Facebook everywhere is great and totally worth it. (I recently also switched back to Windows 10 after a decade+ on Mac OS. I never got satisfactory performance from Firefox on Mac, so part of trying it again was hoping that the perf story on Windows was better, which indeed it is.)
- bongobongo 7y ago
  Switched to Firefox for work and home. It feels like Chrome did in the early days. No, it’s not faster than Chrome. Yes, there are a couple of dev features that I no longer find intuitive. I just mean in the sense that it is really focused on users. Chrome is focused on advertisers. The change has mostly been painless, and I’m a Web developer. At this point I just don’t trust Google nor Chrome. All the incentives are there for Google to turn Chrome into adware. The evidence is pointing in that direction. And the trust is no longer there. It’s funny to think about (and this is of course a gross caricature) but Chrome feels more and more like they took all the annoying adware/bloatware from the 2000s and disguised it in a browser—except they figured out how to do it without anybody noticing. Today, we are all Grandma.
EGreg 7y ago
What is the point of sending cookies to cross-site domains? I never got this. We have postMessage today, and iframes. We have API client information. Third party cookies are restricted anyway, now.
yyyk 7y ago
* Or just ignore Safari because testing it is too expensive due to silly Apple policies. Not all sites need to care about iOS.

tptacek 7y ago

Don't you mean "heckuva job, Safari team"?

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

sieabahlpark 7y ago

News flash, absolutely no one care about chrome breaking the web because Google owns the web. Literally, they're the biggest ad agency, biggest captcha provider (v3 will be on every page if they get their way), biggest browser. Google can and will do whatever they want and there is no amount of complaining that will actually change their mind. Just lookup how they hamfisted their autoplay into the ecosystem despite breaking every website. YouTube is whitelisted to not need to follow their autoplay guidelines though :)

gridlockd 7y ago
> News flash, absolutely no one care about chrome breaking the web because Google owns the web. No they don't. Eight out of the Top Ten websites are not owned by Google. If Chrome became the browser that broke major websites all the time, people would switch really quick. > Just lookup how they hamfisted their autoplay into the ecosystem despite breaking every website. It didn't break "every website", because most websites never had any obnoxious autoplaying media to begin with. Popup Blockers also broke "every website" that had the guts to open pop ups, most of which were not solicited by the user. In either case, strong user preference was behind these changes. It didn't need some consortium of conflicting interests to standardize acceptable website behavior. If users didn't matter and it was all about Google's interests, you wouldn't have adblockers in Chrome. You wouldn't be able to watch Youtube flawlessly without ever seeing any ads.

devinl 7y ago

ITP 2.1 also already says it will block cookies of this type if it matches Safari's completely non-transparent ML model for "tracking cookies". Also Chrome pushed back the release date of this new default from end of August 2019 to February 2020 and the bug has been "fixed in a non-yet released version" of Safari since early June (safari is really slow to release security patches).

kerkeslager 7y ago

As a user, when I visit a site, I never invited some third party to run their code on my computer, and I certainly don't want some third party making requests to the server on my behalf. So screw websites that depend on this bug.

olalonde 7y ago
Just to clarify, CSRF is when a website you visit makes requests on your behalf to a third party (which you have visited/logged into). The third party is also a "victim" of the attack. > I never invited some third party to run their code on my computer This can be achieved by disabling JavaScript (e.g. NoScript extension). As far as I know, there's no extension that can entirely prevent a website from loading resources from other another domain name. If there is, I imagine it would cause a lot of websites to lack styling, images/videos not loading, etc.
- mehhh 7y ago
  uMatrix can be used to block 3rd party resources from loading (like Facebook and Google, usually blockable with no ill effects).
- kerkeslager 7y ago
  Yes, I knew this, and I said the wrong thing anyway, and I am sorry. I didn't think through what I was saying clearly. My intent was more of an "Old Man Yells At Cloud" thing; I was just kvetching because the internet isn't as user-focused as it could be. Calling a bunch of resources from all over the place is a user-hostile behavior, and I'm generally unsympathetic when sites break because browsers narrow the range of user-hostile behaviors they support.

cookiecaper 7y ago

I'm sure this is secretly considered a feature by at least some people inside of Google. Safari's share of the market is already quite small and most MacOS users are able to figure out how to install Chrome (most do so already). If sites magically stop working in Safari, it helps to drive more of that already-weak marketshare to the "just works [because we broke it]" alternative of Chrome.

yyyk 7y ago
All iOS browsers have to use Safari's engine, so users who download Chrome gain nothing in this regard. The only choices available are either to ignore iOS or support Safari.

slowmovintarget 7y ago

At home I've switched back to Firefox. Seems like I need to complete that transition at work to continue enjoying things like ad blocking and functional sites. In fact, maybe sites should start recommending something like that. (Microsoft's wallet sense must be twinging.)

mikepurvis 7y ago
I switched back to Firefox recently as well— the containers plugin has me completely won over. It takes a while to get in the groove of it, but surfing the internet and not being logged into Google and Facebook everywhere is great and totally worth it. (I recently also switched back to Windows 10 after a decade+ on Mac OS. I never got satisfactory performance from Firefox on Mac, so part of trying it again was hoping that the perf story on Windows was better, which indeed it is.)
bongobongo 7y ago
Switched to Firefox for work and home. It feels like Chrome did in the early days. No, it’s not faster than Chrome. Yes, there are a couple of dev features that I no longer find intuitive. I just mean in the sense that it is really focused on users. Chrome is focused on advertisers. The change has mostly been painless, and I’m a Web developer. At this point I just don’t trust Google nor Chrome. All the incentives are there for Google to turn Chrome into adware. The evidence is pointing in that direction. And the trust is no longer there. It’s funny to think about (and this is of course a gross caricature) but Chrome feels more and more like they took all the annoying adware/bloatware from the 2000s and disguised it in a browser—except they figured out how to do it without anybody noticing. Today, we are all Grandma.

EGreg 7y ago

What is the point of sending cookies to cross-site domains? I never got this. We have postMessage today, and iframes. We have API client information. Third party cookies are restricted anyway, now.

yyyk 7y ago

* Or just ignore Safari because testing it is too expensive due to silly Apple policies. Not all sites need to care about iOS.