allowing sameSite="none" ?

[panva]

Should the cookies module get ready for "none" as same-site value?

Resources:

• https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03
• https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
• https://web.dev/samesite-cookies-explained/#other-languages-and-platforms

Finally there is the option of not specifying the value which has previously been the way of implicitly stating that you want the cookie to be sent in all contexts. In the latest draft of RFC6265bis this is being made explicit by introducing a new value of SameSite=None. This means you can use None to clearly communicate you intentionally want the cookie sent in a third-party context.

Bottom line, Chrome will require None as a value to be explicitly used in order to not apply new default eventually. In other words, the current default when sameSite value is not present being the equivalent of a newly specified value None will be Lax.

I believe all that's needed is changing https://github.com/pillarjs/cookies/blob/0.7.3/index.js#L29

[drschasta]

@dougwilson I noticed the PR for this is in the 0.8 milestone and there is no due date for the 0.8 milestone. The version of Chrome that will start requiring samesite=none for 3rd party cookies is scheduled to be in beta today. The stable version will be released July 30th. https://chromestatus.com/features/schedule. Developers need to start implementing this very soon if they want their cookies to accessible on July 30th. Can we expect this build to be out this month? If not, many of us need to make plans to switch to a different library.

[dougwilson]

Hi @drschasta there is no defined due date only because it is "ASAP". A few security issues got priority to this repository, but the due date for this change is still ASAP.

Chrome going forward with the change or not is certainly up in the air, especially since sending SameSite=None causes Safari to incorrectly treat it as SameSite=Strict is still not fixed so will cause a lot of issues using sites with SameSite=None in Safari web browsers (and iPhones, etc.).

[panva]

@dougwilson can you link the Safari issue in question?

[dougwilson]

https://bugs.webkit.org/show_bug.cgi?id=198181

[mariusa]

The Safari issue could be listed in README, rather than blocking implementing support for 'None' in this project.
Looking forward to an update allowing the None value too.

Also, this doc explains 3 possible string values for SameSite. Why not accept a string value and set that, instead of enforcing specific values, including boolean? (which are also different from the spec, 'lax' vs 'Lax', confusing.)
https://web.dev/samesite-cookies-explained

Thanks!

[mariusa]

Also, on case sensitivity:
Quoting from https://stackoverflow.com/questions/5258977/are-http-headers-case-sensitive

Field values may or may not be case-sensitive.

Still, this line always changes it to lowercase:

cookies/index.js

Line 170 in 58dce91

if (this.sameSite ) header += "; samesite=" + (this.sameSite === true ? 'strict' : this.sameSite.toLowerCase())

It seems best to leave as passed by the developer, instead of changing the case. Spec has possible values with first char uppercase: https://web.dev/samesite-cookies-explained

[dougwilson]

Hi @mariusa the Sadari issue is nota blocker; just security fixes in other modules are taking priority. But now your point of case sensitivity is creating a blocker to land this. If you think that is an issue, we now need to have a discussion on your point here before we can continue to merge and release.

[panva]

@mariusa cookie parameter names and their defined values (when predefined values) are matched case-insensitive.

[mariusa]

Thanks for the quick replies. I couldn't find docs on header values being case-insensitive, the closest was the StackOverflow answer linked above (Field values may or may not be case-sensitive.)

Even if it works with both types, as a developer I find it confusing that the library documents some values which are different from the spec. From developer point of view:
I discover setting a header would fix the issue I'm working on. I see this header value on StackOverflow or maybe in spec. Either value, official value is 'Lax' or 'None'. Then I set it in nodejs, since I already set 'maxAge' or something.

My approach (but you know best) would be to check if sameSite attribute is set like this, most permitting way:

if (typeof this.sameSite !== 'undefined') header += "; samesite=" + this.sameSite

That's it. No regexp check, no forcing to lowercase. Let developers set whatever values they want. If browsers will start supporting new values in 2 years, there's no need to update the library. We wouldn't be having this issue :)

Either way, the patch from @panva allows using 'none', which is what this issue is about.

[panva]

@dougwilson an update

1. cookies without SameSite property will be treated as lax by default starting with Chrome 80 (~February 2020)
2. cookies with SameSite=none (what we need to start sending) also need to have the Secure property otherwise they will be rejected.
3. Firefox intents to implement the same (https://groups.google.com/forum/#!msg/mozilla.dev.platform/nx2uP0CzA9k/BNVPWDHsAQAJ)