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

[bugzilla-daemon at webkit.org]

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

--- Comment #5 from Daniel Bates <dbates at webkit.org> ---
(In reply to Mike West from comment #4)
> (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)?

Then it sounds like the inspector patch is wrong (I haven’t looked at it).


> I'm hoping for the former. :)
> 

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

Ok.

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

Ok.

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

Lost the context... What does Safari need to change? Can you please re-contextify me 🙂.

-- 
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/3f5c43ab/attachment.html>