5 ms·

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

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.

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.