[Webkit-unassigned] [Bug 198181] Cookies with SameSite=None or SameSite=invalid treated as Strict

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu May 23 22:15:52 PDT 2019


--- Comment #4 from Mike West <mkwst at chromium.org> ---
(In reply to Daniel Bates from comment #2)
> (In reply to Mike West from comment #1)
> > The patch in https://bugs.webkit.org/show_bug.cgi?id=196927 is only
> > addressing the way cookies are rendered in WebKit's Inspector. I suspect
> > that the underlying behavior is in `NSHTTPCookie`, and will require someone
> > with access to that code to dig into the parser a bit.
> > 
> Yep, and it is has already been fixed if I am remembering correctly. Fix may
> not have shipped, yet.

Does "fixed" mean that `Set-Cookie: name=value; SameSite=InvalidValue` is interpreted as `Set-Cookie: name=value;` (which is what this bug is asking for)? Or as `Set-Cookie: name=value; SameSite=Strict` (which is what that Inspector patch does)? I'm hoping for the former. :)

> Wait, I haven’t seen “None” before. If this does something other than
> nothing (i.e. implementer does not even need to parse ‘n’, ‘o’, ‘n’, ‘e’,
> then ^^^ is enough.

`SameSite=None` is intended to be a no-op in the status quo. That is, it assumes the first interpretation of "fixed" above, wherein `SameSite=None` is equivalent to omitting the `SameSite` attribute entirely.

I'll paste in a little more context here from the thread you started elsewhere:

That document proposes that `SameSite=Lax` is a better default than we have today, and positions `None` as an explicit way of opting into the status quo. `SameSite=None` should be a no-op based on the above PR, and it seemed like an elegant, backwards-compatible way of allowing developers to explicitly express their intent for a given cookie to be delivered cross-site. I talked about the general direction with folks at the recent HTTP Workshop, and there seemed to be reasonable agreement that incrementally shifting cookes' defaults would be a good way to make progress.

If Safari's able to change the underlying parsing behavior in the near future, this seems like a path we can pursue. If not, we might need to introduce another attribute in order to get that behavior in a way that doesn't break in other browsers.

> If there any other visible change then CFNetwork will
> need to be involved and we need a radar, which you can create yourself
> assigned to the right place (I think) at bugreport.apple.com. Ehh, as I type
> this, I guess its not much work to CC the WebKit-radar-importer and then do
> a radar dance Internally 😕

Thank you. :)

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190524/32ecb05d/attachment.html>

More information about the webkit-unassigned mailing list