7 ms·

Improving privacy and security on the web

121 points by migueldemoura 7y ago

Ajedi32 7y ago
Interesting. So apparently Chrome is going to stop sending cookies in cross-site requests unless they're created with `CrossOrigin=None` and the page is loaded over HTTPS?
- mikewest 7y ago
  We're proposing treating cookies as `SameSite=Lax` by default (https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03...). Developers would be able to opt-into the status quo by explicitly asserting `SameSite=None`, but to do so, they'll also need to ensure that their cookies won't be delivered over non-secure transport by asserting the `Secure` attribute as well. https://tools.ietf.org/html/draft-west-cookie-incrementalism https://tools.ietf.org/html/draft-west-cookie-incrementalism spells out the proposal in a bit more detail.
  - Boulth 7y ago
    This is exactly the information I was looking for when I opened chromium blog post. Technical and to the point. Is there a reason why this couldn't be appended to the blog post?
    - tptacek 7y ago
      Because you aren't really the audience for that post, and they can safely assume you'll dig deeper anyways?
      - tedivm 7y ago
        If we're not the audience then who is? This was made to the Chromium open source blog, which is typically a developer heavy blog (with previous topics like "Hint for low latency canvas contexts"). Throwing a few reference links at the bottom shouldn't harm their message with the less technically savvy.
        tptacek 7y ago
        I'm just guessing. Something else that sparks joy for me: the fact that Google will never give any of their announcements the titles they're justifying, like, "OMG, WE KILLED CSRF!", and that I'll have to dig in a bit to see how big a deal what they just did is. It's like every "Improving privacy and security on the web" is a little gift I get to unwrap. It's like Justin Schuh and Mike West's version of "one more thing".
        vatueil 7y ago
        A few more reference links might not hurt, true. As for who the audience is, perhaps people who were alarmed by the WSJ's scaremongering: https://www.wsj.com/articles/googles-new-privacy-tools-to-make-cookies-crumble-competitors-stumble-11557151913 https://www.wsj.com/articles/googles-new-privacy-tools-to-ma... Someone leaked the news to the WSJ, which tried to spin this as an anti-competitive move.
        bgalbs 7y ago
        Good feedback. Chromium blog content varies from product announcements to technical summaries. We did link to this article in the Chromium blog: <https://web.dev/samesite-cookies-explained/> https://web.dev/samesite-cookies-explained/> which does go into a good deal of technical detail. A challenge is that even experienced web developers didn't know much about SameSite prior to this announcement.
  - est31 7y ago
    Have you done some crawling or other means of checking as to how many web pages with a login your change would break?
    - mikewest 7y ago
      Unfortunately, crawling isn't a terribly effective way of evaluating breakage, as the crawler doesn't sign-in, and therefore doesn't attempt to federate sign-in across multiple sites. That's part of the reason that we're not shipping this change today, but proposing it as a (near-)future step. To that end, we've implemented the change behind two flags (chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure) so that we can work with developers to help them migrate cookies that need to be accessible cross-site to `SameSite=None; Secure`. Ideally, we won't unintentionally break anything when we're confident enough to ship this change.
  - raxxorrax 7y ago
    I think this is a well thought out proposal. Thank you for going in that direction. Privacy and security should come first. I would even go so far to substitute "should" with "must". But it is a first step.
34r45sdg 7y ago
Is this another way for Google to prevent you from clearing their cookies via the 'Clear Cookies' option? Its a step in the right direction with enforcing SameSite cookie scoping, but we must be cautious that Google doesn't use this to force you to always be logged in. Google has a long way to go to rebuild trust after that last browser login debacle. I don't trust em.
- wheelerwj 7y ago
  google will absolutely not do anything in the name of trust and privacy as we define them because their business model is 100% about selling ads to more people.
- jakub_g 7y ago
  It's a way to fix one of the biggest security mistakes of the web (being able to send an _authenticated_ request - i.e. with cookies - to any domain from any other domain, for example from evil.com to youremailprovider.com with the payload "delete all emails"), that was kept on by default for two decades due to backward compatibility. For a long time it required annoying workarounds (CSRF tokens) to have this security hole mitigated, then just an opt-in flag on the cookies, but as usual, most companies don't know/care about it, so having protection by default is the natural solution (although it _will_ probably break quite a few legacy websites, but for a greater good).
- incompatible 7y ago
  Does Chrome support automatically clearing cookies at shutdown yet? I seem to remember it didn't but I haven't used it recently. Edit: I searched for it, and it seems they have added the feature, but maybe not the related feature of clearing browsing history at shutdown.
  - jedimastert 7y ago
    Isn't that exactly what Incognito mode does?
techntoke 7y ago
Really disappointed in you Google for not addressing fingerprinting much sooner.
- tptacek 7y ago
  Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.
  - techntoke 7y ago
    It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.
    - ayrx 7y ago
      You will be part of the rare minority that uses that configuration which by itself is a fingerprint.
      - anonymfus 7y ago
        The point probably was to make that configuration default
        tptacek 7y ago
        That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.
        progval 7y ago
        You can do a lot of things with just HTML and CSS, more than what Gopher allows. And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX
tptacek 7y ago
Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, those requests will no longer carry cookies. To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today. Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies. As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.
- Lx1oG-AWb6h_ZG0 7y ago
  Before you start emitting samesite=lax, be warned that webkit/safari iOS12 has a weird implementation: if you set the cookie in a POST method and redirect to a GET (like most default oauth explicit grant login flows), the cookie will not be sent: they consider POST pages as "unsafe". See https://bugs.webkit.org/show_bug.cgi?id=188165#c12 https://bugs.webkit.org/show_bug.cgi?id=188165#c12 for more details. Edit: it looks like people have found other issues since I last looked at this bug: > It's a serious issue affecting many common user flows, including the flow of visiting a website coming from a GMail link. If the user comes from GMail, it reaches the destination website without any cookies, thereby breaking functionalities that depend on session/login cookie and CSRF cookie. Only fix for now seems to be removing the Lax flag from cookies. (https://bugs.webkit.org/show_bug.cgi?id=188165#c47 https://bugs.webkit.org/show_bug.cgi?id=188165#c47) At this point, it looks like the safest approach is to only emit sameSite if the browser isn't safari.
  - mikewest 7y ago
    We did just clarify this in the spec: https://github.com/httpwg/http-extensions/commit/49bcb4fddb8a8c294749ec9d81a236cde4df94b0 https://github.com/httpwg/http-extensions/commit/49bcb4fddb8.... Hopefully that, plus the tests we'll add in https://bugs.chromium.org/p/chromium/issues/detail?id=960375 https://bugs.chromium.org/p/chromium/issues/detail?id=960375 will help other vendors align their behavior with developer expectations.
zzzzzzqzzzzzz 7y ago
Not that any step towards additional privacy protections isn't a good thing, same for security. But Google has got to be one of the major contributors to the erosion of privacy. How about chrome nagging to have you sign in? How about their very own ad networks?
- techntoke 7y ago
  You mean like Firefox sync and Pocket? The so called founder of JavaScript was the CEO of Mozilla, and that is the biggest cause of erosion of privacy on the web.
  - zzzzzzqzzzzzz 7y ago
    Absolutely. I should have the option to use a browser, be it Firefox or Chrome, without unwanted integrations or 'features'. I'd like a browser that just browses the internet and respects my privacy. But apparently that's too much to ask
    - olliej 7y ago
      You mean like Safari? ;D
    - dredmorbius 7y ago
      Surf / Suckless: https://surf.suckless.org https://surf.suckless.org
deleted 7y ago
[deleted]
akersten 7y ago
This is great - the `SameSite=lax` attribute is arguably how cookies should have worked in the first place, and I'm quite pleased that it's an existing RFC and not a proprietary change being done just in Chrome. Hopefully other browsers follow suit. What worries me is the vague commitment to stop browser fingerprinting - not a lot of detail there and I'm fearful that useful features might be getting crippled. I don't think I'm as convinced that browser fingerprinting is as big of an issue as CSRF (prevented by the cookie changes here). Time will tell I suppose.
- Ajedi32 7y ago
  The reason this is related to browser fingerprinting is that cross-site cookies aren't _just_ used for CSRF, they're also a way to track users across sites. With this change, developers will have to _explicitly_ declare when they're using cookies for that purpose (by setting SameSite=none) which makes it easier for browsers to identify cookies used for tracking and give users control over them.
niftich 7y ago
This is a continuation of a long arc of convergent work [1][2][3][4][5] by various people over several years; I've been following along [6]. The innovation of this proposal is to work towards the crossdomain cookie transmission being less insecure-by-default, by eventually making the current, limitless behavior opt-in. This shifts the incentive of developers: presumably those whose sites require crossdomain acceptance of cookies will modify their sites accordingly, while those whose sites don't, or those who haven't thought about the issue will see fewer incidences of the most egregious POST-based CSRF. [1] https://www.microsoft.com/en-us/research/publication/atlantis-robust-extensible-execution-environments-for-web-applications/ https://www.microsoft.com/en-us/research/publication/atlanti... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=795346 https://bugzilla.mozilla.org/show_bug.cgi?id=795346 [3] https://github.com/mozmark/SameDomain-cookies/blob/master/samedomain.txt https://github.com/mozmark/SameDomain-cookies/blob/master/sa... [4] http://homakov.blogspot.com/2013/02/rethinking-cookies-originonly.html http://homakov.blogspot.com/2013/02/rethinking-cookies-origi... [5] https://tools.ietf.org/html/draft-west-first-party-cookies-07 https://tools.ietf.org/html/draft-west-first-party-cookies-0... [6] https://news.ycombinator.com/item?id=13689697#13691022 https://news.ycombinator.com/item?id=13689697#13691022
driverdan 7y ago
The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.
- om2 7y ago
  Safari's Intelligent Tracking Prevention effectively blocks third-party cookies, at least for resources that are used in a third-party context on multiple sites. This google Chrome proposal also does it, but provides a dead simple workaround for trackers by sending SameSite=None and Secure with the cookie.
  - user17843 7y ago
    Let me guess: Google will tie the new proposal to a new Chrome setting which effectively identifies tracking cookies according to this new identifier, and will regularly purge them.
- propogandist 7y ago
  This will never happen. Google's entire ecosystem is built around advertising, so everything is an illusion of privacy. Things like 3rd party cookies will be the norm and Google won't block them, although firefox has started to head down that direction. Chrome mobile, for example, can support add-ons and privacy features, but the risk to ad revenue is preventing them from making it available. Chrome being the default browser for Android means most people won't switch and they have >~80% marketshare.
fenwick67 7y ago
Why do cross-domain requests need cookies at all? Honest question, why couldn't we just stop sending them ever?
- actimia 7y ago
  At my company for example we run services on multiple domains that are all authenticated by a single backend. Could probably be solved by some re-architecturing, but changing cookie behaviour would definitly break existing sites.
sempron64 7y ago
Is there a timeline for this change?

121 points by migueldemoura 7y ago

Interesting. So apparently Chrome is going to stop sending cookies in cross-site requests unless they're created with `CrossOrigin=None` and the page is loaded over HTTPS?

mikewest 7y ago
We're proposing treating cookies as `SameSite=Lax` by default (https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03...). Developers would be able to opt-into the status quo by explicitly asserting `SameSite=None`, but to do so, they'll also need to ensure that their cookies won't be delivered over non-secure transport by asserting the `Secure` attribute as well. https://tools.ietf.org/html/draft-west-cookie-incrementalism https://tools.ietf.org/html/draft-west-cookie-incrementalism spells out the proposal in a bit more detail.
- Boulth 7y ago
  This is exactly the information I was looking for when I opened chromium blog post. Technical and to the point. Is there a reason why this couldn't be appended to the blog post?
  - tptacek 7y ago
    Because you aren't really the audience for that post, and they can safely assume you'll dig deeper anyways?
    - tedivm 7y ago
      If we're not the audience then who is? This was made to the Chromium open source blog, which is typically a developer heavy blog (with previous topics like "Hint for low latency canvas contexts"). Throwing a few reference links at the bottom shouldn't harm their message with the less technically savvy.
      - tptacek 7y ago
        I'm just guessing. Something else that sparks joy for me: the fact that Google will never give any of their announcements the titles they're justifying, like, "OMG, WE KILLED CSRF!", and that I'll have to dig in a bit to see how big a deal what they just did is. It's like every "Improving privacy and security on the web" is a little gift I get to unwrap. It's like Justin Schuh and Mike West's version of "one more thing".
      - vatueil 7y ago
        A few more reference links might not hurt, true. As for who the audience is, perhaps people who were alarmed by the WSJ's scaremongering: https://www.wsj.com/articles/googles-new-privacy-tools-to-make-cookies-crumble-competitors-stumble-11557151913 https://www.wsj.com/articles/googles-new-privacy-tools-to-ma... Someone leaked the news to the WSJ, which tried to spin this as an anti-competitive move.
      - bgalbs 7y ago
        Good feedback. Chromium blog content varies from product announcements to technical summaries. We did link to this article in the Chromium blog: <https://web.dev/samesite-cookies-explained/> https://web.dev/samesite-cookies-explained/> which does go into a good deal of technical detail. A challenge is that even experienced web developers didn't know much about SameSite prior to this announcement.
- est31 7y ago
  Have you done some crawling or other means of checking as to how many web pages with a login your change would break?
  - mikewest 7y ago
    Unfortunately, crawling isn't a terribly effective way of evaluating breakage, as the crawler doesn't sign-in, and therefore doesn't attempt to federate sign-in across multiple sites. That's part of the reason that we're not shipping this change today, but proposing it as a (near-)future step. To that end, we've implemented the change behind two flags (chrome://flags/#same-site-by-default-cookies and chrome://flags/#cookies-without-same-site-must-be-secure) so that we can work with developers to help them migrate cookies that need to be accessible cross-site to `SameSite=None; Secure`. Ideally, we won't unintentionally break anything when we're confident enough to ship this change.
- raxxorrax 7y ago
  I think this is a well thought out proposal. Thank you for going in that direction. Privacy and security should come first. I would even go so far to substitute "should" with "must". But it is a first step.

34r45sdg 7y ago

Is this another way for Google to prevent you from clearing their cookies via the 'Clear Cookies' option? Its a step in the right direction with enforcing SameSite cookie scoping, but we must be cautious that Google doesn't use this to force you to always be logged in. Google has a long way to go to rebuild trust after that last browser login debacle. I don't trust em.

wheelerwj 7y ago
google will absolutely not do anything in the name of trust and privacy as we define them because their business model is 100% about selling ads to more people.
jakub_g 7y ago
It's a way to fix one of the biggest security mistakes of the web (being able to send an _authenticated_ request - i.e. with cookies - to any domain from any other domain, for example from evil.com to youremailprovider.com with the payload "delete all emails"), that was kept on by default for two decades due to backward compatibility. For a long time it required annoying workarounds (CSRF tokens) to have this security hole mitigated, then just an opt-in flag on the cookies, but as usual, most companies don't know/care about it, so having protection by default is the natural solution (although it _will_ probably break quite a few legacy websites, but for a greater good).
incompatible 7y ago
Does Chrome support automatically clearing cookies at shutdown yet? I seem to remember it didn't but I haven't used it recently. Edit: I searched for it, and it seems they have added the feature, but maybe not the related feature of clearing browsing history at shutdown.
- jedimastert 7y ago
  Isn't that exactly what Incognito mode does?

techntoke 7y ago

Really disappointed in you Google for not addressing fingerprinting much sooner.

tptacek 7y ago
Be disappointed all you want, but they're not really "addressing" fingerprinting. It is exceptionally difficult --- computer-science Hard difficult --- to prevent fingerprinting; all you can really do is break popular libraries people use today. It's an arms race, and a much harder arms race than exploit-hardened runtimes are.
- techntoke 7y ago
  It's actually pretty easy overall... just don't use JavaScript and don't send user-agent string that shows browser/OS information.
  - ayrx 7y ago
    You will be part of the rare minority that uses that configuration which by itself is a fingerprint.
    - anonymfus 7y ago
      The point probably was to make that configuration default
      - tptacek 7y ago
        That configuration will not be the default. You might just as productively argue that the best way to defeat fingerprinting would be to default to Gopher.
        progval 7y ago
        You can do a lot of things with just HTML and CSS, more than what Gopher allows. And for what you can't, a banner asking for permission to run Javascript, like we have/had for Java/Flash/ActiveX

tptacek 7y ago

Wow, if this works, this is basically the end of CSRF. Essentially: CSRF relies on an HTTP POST to VICTIM.COM triggered by HTML on EVIL.COM, and that request carrying cookies. Today, even though SameSite exists, the default --- SameSite=None --- maintains that longstanding status quo. But after the change, the Chrome default will be SameSite=Lax, and while EVIL.COM will still be able to trigger POSTs to VICTIM.COM, those requests will no longer carry cookies. To get the cookies to work from EVIL.COM, VICTIM.COM's developers will have to explicitly set SameSite=None on their session cookies. Which nobody will do, because nobody sets SameSite at all today. Better still: 99 out of 100 CSRF exploits (maybe 999 out of 1000) target endpoints for which SameSite=None isn't needed; they're cookies nobody ever uses cross-site to begin with. There are only limited cases where anyone needs the behavior to change, and those cases don't track the most sensitive cookies. As a vulnerability researcher for whom exploitable bugs mostly exist to spark joy: good riddance to CSRF. It was a dumb bug class, and never, ever fun to exploit.

Lx1oG-AWb6h_ZG0 7y ago
Before you start emitting samesite=lax, be warned that webkit/safari iOS12 has a weird implementation: if you set the cookie in a POST method and redirect to a GET (like most default oauth explicit grant login flows), the cookie will not be sent: they consider POST pages as "unsafe". See https://bugs.webkit.org/show_bug.cgi?id=188165#c12 https://bugs.webkit.org/show_bug.cgi?id=188165#c12 for more details. Edit: it looks like people have found other issues since I last looked at this bug: > It's a serious issue affecting many common user flows, including the flow of visiting a website coming from a GMail link. If the user comes from GMail, it reaches the destination website without any cookies, thereby breaking functionalities that depend on session/login cookie and CSRF cookie. Only fix for now seems to be removing the Lax flag from cookies. (https://bugs.webkit.org/show_bug.cgi?id=188165#c47 https://bugs.webkit.org/show_bug.cgi?id=188165#c47) At this point, it looks like the safest approach is to only emit sameSite if the browser isn't safari.
- mikewest 7y ago
  We did just clarify this in the spec: https://github.com/httpwg/http-extensions/commit/49bcb4fddb8a8c294749ec9d81a236cde4df94b0 https://github.com/httpwg/http-extensions/commit/49bcb4fddb8.... Hopefully that, plus the tests we'll add in https://bugs.chromium.org/p/chromium/issues/detail?id=960375 https://bugs.chromium.org/p/chromium/issues/detail?id=960375 will help other vendors align their behavior with developer expectations.

zzzzzzqzzzzzz 7y ago

Not that any step towards additional privacy protections isn't a good thing, same for security. But Google has got to be one of the major contributors to the erosion of privacy. How about chrome nagging to have you sign in? How about their very own ad networks?

techntoke 7y ago
You mean like Firefox sync and Pocket? The so called founder of JavaScript was the CEO of Mozilla, and that is the biggest cause of erosion of privacy on the web.
- zzzzzzqzzzzzz 7y ago
  Absolutely. I should have the option to use a browser, be it Firefox or Chrome, without unwanted integrations or 'features'. I'd like a browser that just browses the internet and respects my privacy. But apparently that's too much to ask
  - olliej 7y ago
    You mean like Safari? ;D
  - dredmorbius 7y ago
    Surf / Suckless: https://surf.suckless.org https://surf.suckless.org

deleted 7y ago

[deleted]

akersten 7y ago

This is great - the `SameSite=lax` attribute is arguably how cookies should have worked in the first place, and I'm quite pleased that it's an existing RFC and not a proprietary change being done just in Chrome. Hopefully other browsers follow suit. What worries me is the vague commitment to stop browser fingerprinting - not a lot of detail there and I'm fearful that useful features might be getting crippled. I don't think I'm as convinced that browser fingerprinting is as big of an issue as CSRF (prevented by the cookie changes here). Time will tell I suppose.

Ajedi32 7y ago
The reason this is related to browser fingerprinting is that cross-site cookies aren't _just_ used for CSRF, they're also a way to track users across sites. With this change, developers will have to _explicitly_ declare when they're using cookies for that purpose (by setting SameSite=none) which makes it easier for browsers to identify cookies used for tracking and give users control over them.

niftich 7y ago

This is a continuation of a long arc of convergent work [1][2][3][4][5] by various people over several years; I've been following along [6]. The innovation of this proposal is to work towards the crossdomain cookie transmission being less insecure-by-default, by eventually making the current, limitless behavior opt-in. This shifts the incentive of developers: presumably those whose sites require crossdomain acceptance of cookies will modify their sites accordingly, while those whose sites don't, or those who haven't thought about the issue will see fewer incidences of the most egregious POST-based CSRF. [1] https://www.microsoft.com/en-us/research/publication/atlantis-robust-extensible-execution-environments-for-web-applications/ https://www.microsoft.com/en-us/research/publication/atlanti... [2] https://bugzilla.mozilla.org/show_bug.cgi?id=795346 https://bugzilla.mozilla.org/show_bug.cgi?id=795346 [3] https://github.com/mozmark/SameDomain-cookies/blob/master/samedomain.txt https://github.com/mozmark/SameDomain-cookies/blob/master/sa... [4] http://homakov.blogspot.com/2013/02/rethinking-cookies-originonly.html http://homakov.blogspot.com/2013/02/rethinking-cookies-origi... [5] https://tools.ietf.org/html/draft-west-first-party-cookies-07 https://tools.ietf.org/html/draft-west-first-party-cookies-0... [6] https://news.ycombinator.com/item?id=13689697#13691022 https://news.ycombinator.com/item?id=13689697#13691022

driverdan 7y ago

The easiest way to improve cookie privacy is to block 3rd party cookies by default. Adding new polices is not the right solution. 3rd party cookies are completely unnecessary.

om2 7y ago
Safari's Intelligent Tracking Prevention effectively blocks third-party cookies, at least for resources that are used in a third-party context on multiple sites. This google Chrome proposal also does it, but provides a dead simple workaround for trackers by sending SameSite=None and Secure with the cookie.
- user17843 7y ago
  Let me guess: Google will tie the new proposal to a new Chrome setting which effectively identifies tracking cookies according to this new identifier, and will regularly purge them.
propogandist 7y ago
This will never happen. Google's entire ecosystem is built around advertising, so everything is an illusion of privacy. Things like 3rd party cookies will be the norm and Google won't block them, although firefox has started to head down that direction. Chrome mobile, for example, can support add-ons and privacy features, but the risk to ad revenue is preventing them from making it available. Chrome being the default browser for Android means most people won't switch and they have >~80% marketshare.

fenwick67 7y ago

Why do cross-domain requests need cookies at all? Honest question, why couldn't we just stop sending them ever?

actimia 7y ago
At my company for example we run services on multiple domains that are all authenticated by a single backend. Could probably be solved by some re-architecturing, but changing cookie behaviour would definitly break existing sites.

sempron64 7y ago

Is there a timeline for this change?