Bug 198181 – Cookies with SameSite=None or SameSite=invalid treated as Strict

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Rowan Merewood]

Cookies specifying `SameSite=None` or sending an invalid value, e.g. `SameSite=nonsense` appear to be treated as `Strict` and are therefore not being sent with cross-site requests as intended.

There is this recent bug: https://bugs.webkit.org/show_bug.cgi?id=196927 which appears related and also references https://httpwg.org/http-extensions/rfc6265bis.html#the-samesite-attribute-1 for the correct behaviour.

You can see this demonstrated in this example:

1. Set a range of cookies with different `SameSite` values:
https://peaceful-wing.glitch.me/setcookies

2. Verify those cookies are set in a same-site context:
https://peaceful-wing.glitch.me/

3. See which cookies are sent in a cross-site context:
https://merewood.org/samesite.html

From the example site's output
Expected cookies in the cross-site context:
{
    "remote-site-unspecified": "unspecified",
    "remote-site-none-nosecure": "none",
    "remote-site-none-secure": "none-secure",
    "remote-site-nonsense": "nonsense"
}

Actual cookies in the cross-site context:
{
    "remote-site-unspecified": "unspecified"
}

[Mike West]

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.

FWIW, Chrome, Firefox, and Edge (old and new) all treat `SameSite=UnknownValue` as though the `SameSite` attribute wasn't present. That's fairly forward-compatible for cases in which we decide collectively that a new value is reasonable to add.

Would it be possible for y'all to revisit this behavior? It's going to make shipping https://tools.ietf.org/html/draft-west-cookie-incrementalism-00 somewhat difficult for developers to handle without carving out special behavior for Safari, for example.

/cc dbates@, wilander@, joepeck@.

[Daniel Bates]

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

> FWIW, Chrome, Firefox, and Edge (old and new) all treat
> `SameSite=UnknownValue` as though the `SameSite` attribute wasn't present.
> That's fairly forward-compatible for cases in which we decide collectively
> that a new value is reasonable to add.
> 
> Would it be possible for y'all to revisit this behavior? It's going to make
> shipping https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> somewhat difficult for developers to handle without carving out special
> behavior for Safari, for example.
> 

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

> /cc dbates@, wilander@, joepeck@.

[Daniel Bates]

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

Fixed in <rdar://problem/42290578>. Not shipped. 🤷‍♂️ when.

[Mike West]

(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. :)

[Daniel Bates]

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

[Mike West]

(In reply to Daniel Bates from comment #5)
> Then it sounds like the inspector patch is wrong (I haven’t looked at it).

+joepeck@.

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

It sounds like shipping the fix from rdar://problem/42290578 would be sufficient. Just because I'm not familiar with y'all's release process: does a `CFNetwork` update require an OS update, or do you bundle it with Safari pushes? Likewise, I imagine it would require changes in both macOS and iOS?

I recognize that it's difficult to make predictions about the future, but we're trying to figure out a reasonable timeline for shifting to `SameSite=Lax` by default, and it would be lovely to not break Safari users as we do it. If this is a fix that will be widely-deployed soon, great! If not, we might need to rethink our plans (possibly requiring adding more complexity to cookies with some additional attribute that Safari would safely ignore). I'd kinda like to avoid doing that if possible...

[Joseph Pecoraro]

> > > Yep, and it is has already been fixed if I am remembering correctly. Fix may
> > > not have shipped, yet.

Correct, I don't believe the CFNetwork change has shipped yet. I waited to change Web Inspector until our Network stack made the change. 


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

Web Inspector should be doing the former:
https://trac.webkit.org/browser/trunk/Source/WebInspectorUI/UserInterface/Models/Cookie.js#L117


```
    static parseSameSiteAttributeValue(attributeValue)
    {
        if (!attributeValue)
            return WI.Cookie.SameSiteType.None;

        switch (attributeValue.toLowerCase()) {
        case "lax":
            return WI.Cookie.SameSiteType.Lax;
        case "strict":
            return WI.Cookie.SameSiteType.Strict;
        }

        return WI.Cookie.SameSiteType.None;
    }
```

We also have tests:
https://trac.webkit.org/browser/trunk/LayoutTests/inspector/unit-tests/cookie.html#L173

```
    // SameSite with unknown value is ignored.
    test(`name=value; SameSite=invalid`, {
        name: "name",
        value: "value",
        expires: null,
        maxAge: null,
        path: null,
        domain: null,
        secure: false,
        httpOnly: false,
        sameSite: WI.Cookie.SameSiteType.None,
    });
```

This was all done in:
https://bugs.webkit.org/show_bug.cgi?id=196927

    commit 10b4574f710b67f24dc0b219b9c0f67a2014f101
    Author: [e-mail] <[e-mail]@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
    Date:   Mon Apr 15 21:53:48 2019 +0000

        Web Inspector: SameSite parsing should be stricter
        https://bugs.webkit.org/show_bug.cgi?id=196927
        <rdar://problem/42291601>

--

• Are you seeing otherwise?
• Are you using Safari Technology Preview?

[Joseph Pecoraro]

In STPv83 if I load:
https://peaceful-wing.glitch.me/setcookies

I see "–" in the SameSite column for the `Set-Cookie: remote-site-nonsense=nonsense; SameSite=Nonsense` response cookie.

[Mike West]

(In reply to Joseph Pecoraro from comment #8)
> In STPv83 if I load:
> https://peaceful-wing.glitch.me/setcookies
> 
> I see "–" in the SameSite column for the `Set-Cookie:
> remote-site-nonsense=nonsense; SameSite=Nonsense` response cookie.

Great! In that case, I think I just misread the patch, thanks for the correction; I'm happy to see this works exactly the way I thought it didn't. :)

We still need to wait for an OS update in order to pull in the networking side of the fix, though, correct?

[Joseph Pecoraro]

> We still need to wait for an OS update in order to pull in the networking
> side of the fix, though, correct?

Correct.

[Rowan Merewood]

This does look to be fixed in the iOS 13 beta (which is grand 🎉). Is there any view as to whether this will make it into 12?

[John Wilander]

(In reply to Rowan Merewood from comment #11)
> This does look to be fixed in the iOS 13 beta (which is grand 🎉). Is there
> any view as to whether this will make it into 12?

I don't think the CFNetwork change is in the iOS 12.4 beta but iOS 12.4 beta 5 was released recently if you want to check: https://developer.apple.com/documentation/ios_ipados_release_notes/ios_12_4_beta_5_release_notes

[Joseph Pecoraro]

Great! Can we mark this as resolved?

[Mike West]

(In reply to Joseph Pecoraro from comment #13)
> Great! Can we mark this as resolved?

Yes. It's fixed in y'all's codebase. Now we're just waiting for deployment. Thank you!

Note that Chrome is currently targeting ~M80 (February) to push a `SameSite=None` requirement on third-party cookies (https://www.chromestatus.com/feature/5088147346030592). That seems like it'll be enough time for a critical mass of Safari users to upgrade to macOS 10.15 and iOS 13. It still leaves folks whose devices supported Safari 12 but won't support Safari 13 in a somewhat uncomfortable position, and we're likely going to need to recommend UA sniffing to avoid harm to that population.

If y'all could work out a way to get the underlying network stack change into a point release of either or both macOS 10.14 and iOS 12, it would both make that timeline more solid, and potentially allow us to be more aggressive with the timeline generally with less risk.

Thanks again for your help here!

[Radar WebKit Bug Importer]

<rdar://problem/52320694>

[John Wilander]

(In reply to Mike West from comment #14)
> (In reply to Joseph Pecoraro from comment #13)
> > Great! Can we mark this as resolved?
> 
> Yes. It's fixed in y'all's codebase. Now we're just waiting for deployment.
> Thank you!
> 
> Note that Chrome is currently targeting ~M80 (February) to push a
> `SameSite=None` requirement on third-party cookies
> (https://www.chromestatus.com/feature/5088147346030592). That seems like
> it'll be enough time for a critical mass of Safari users to upgrade to macOS
> 10.15 and iOS 13. It still leaves folks whose devices supported Safari 12
> but won't support Safari 13 in a somewhat uncomfortable position, and we're
> likely going to need to recommend UA sniffing to avoid harm to that
> population.
> 
> If y'all could work out a way to get the underlying network stack change
> into a point release of either or both macOS 10.14 and iOS 12, it would both
> make that timeline more solid, and potentially allow us to be more
> aggressive with the timeline generally with less risk.
> 
> Thanks again for your help here!

I filed rdar://52330350 for investigating a backport of the network stack change.

[Lily Chen]

Hi, is there any update on the status of the backport for this fix?

(In reply to John Wilander from comment #16)
> I filed rdar://52330350 for investigating a backport of the network stack
> change.

Hello John, was a backport feasible for this fix? Will this be backported to iOS 12? Thanks!

[John Wilander]

(In reply to billy.richardson from comment #18)
> (In reply to John Wilander from comment #16)
> > I filed rdar://52330350 for investigating a backport of the network stack
> > change.
> 
> Hello John, was a backport feasible for this fix? Will this be backported to
> iOS 12? Thanks!

Lily and Billy, unfortunately it's not looking good for a backport. We argued the case and the people responsible for the HTTP stack understand the issue. But I think it's wise for you to take into consideration that we may never see support for SameSite=None on iOS 12 (and back).

[Kalle]

This will be a major headache for anyone who needs to use SameSite=None

Does anyone have any good suggestions on what to use for user agent sniffing to exclude all devices that treat SameSite=None as SameSite=Strict?

[Robert Slaney]

We need firm advice on how to detect non-confirming versions of Safari.

UA sniffing is fragile at best and I don't want to have to exclude more than I need to

[John Wilander]

(In reply to Robert Slaney from comment #21)
> We need firm advice on how to detect non-confirming versions of Safari.
> 
> UA sniffing is fragile at best and I don't want to have to exclude more than
> I need to

We understand the concern, but this is not caused by WebKit or CFNetwork. This is Chrome planning to change the default behavior of cookies and nicely asking us if we can backport the change to support them. You should primarily bring your concerns to the Chrome team.

[Robert Slaney]

Hey John...

I appreciate the position that Chrome devs have put us all in.  I have an end user base that I am accountable to and I can whinge till the cows come home but it won't make a difference.

I don't need this fix to be backported but I need to know when I have to change our systems' behaviour and UA sniffing is the only reasonable answer at this point.

so....

Is there a range of version numbers of Safari, MacOS, and/or iOS that I need to detect so I do NOT supply the SameSite=None cookie flag when required.

To be honest, the Safari product set is not our primary browser segment so if I ( and I suspect a majority of corporates are in the same position ) have to put a stake in the ground then the users of non-conforming browsers will be impacted.

Hey Robert,
My team and I are in the same position as you.

I am currently not sending the SameSite cookie attribute to the following User Agents:

^.*iPhone; CPU iPhone OS 1[0-2].*$
^.*iPad; CPU OS 1[0-2].*$
^.*iPod touch; CPU iPhone OS 1[0-2].*$
^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$

This has been in place in our Production for several weeks without any user complaints. As always, you should verify yourself too :)

Regards,
Billy Richardson

[Andrew Soderberg]

(In reply to Robert Slaney from comment #23)

In case you had not seen these yet, I found the following articles that describe how to support non-conforming browsers that do not know how to handle 'SameSite=None' without having to resort to potentially 'complex and brittle' User-Agent (UA) Sniffing:

https://auth0.com/blog/browser-behavior-changes-what-developers-need-to-know/

https://web.dev/samesite-cookie-recipes/

/cc robert.slaney@, billy.richardson@, kaoskaoskaoskaos@.

(In reply to Andrew Soderberg from comment #25)
> (In reply to Robert Slaney from comment #23)
> 
> In case you had not seen these yet, I found the following articles that
> describe how to support non-conforming browsers that do not know how to
> handle 'SameSite=None' without having to resort to potentially 'complex and
> brittle' User-Agent (UA) Sniffing:
> 
> https://auth0.com/blog/browser-behavior-changes-what-developers-need-to-know/
> 
> https://web.dev/samesite-cookie-recipes/
> 
> /cc robert.slaney@, billy.richardson@, kaoskaoskaoskaos@.

Hi Andrew,
Those links don't quite cover the case here.
For example, in the second link you gave it mentions the below:
1) "Cookies without a SameSite attribute will be treated as SameSite=Lax[..]"
2) "Cookies for cross-site usage must specify SameSite=None; Secure to enable inclusion in third party context."

Setting SameSite=None in Safari 12 is the same as setting SameSite=Strict (as per this bug). If SameSite=None must be set (so Chrome does not default to SameSite=Lax as per #1 above), then Safari is in turn broken as it will treat the cookie as SameSite=Strict.

This means that the server needs to selectively _not send_ SameSite=None to Safari 12 (so the cookie is not treated as SameSite=Strict) and _send_ SameSite=None to Chrome (so the cookie is not defaulted to SameSite=Lax).

[achkim]

(In reply to billy.richardson from comment #24)
> Hey Robert,
> My team and I are in the same position as you.
> 
> I am currently not sending the SameSite cookie attribute to the following
> User Agents:
> 
> ^.*iPhone; CPU iPhone OS 1[0-2].*$
> ^.*iPad; CPU OS 1[0-2].*$
> ^.*iPod touch; CPU iPhone OS 1[0-2].*$
> ^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$
> 
> This has been in place in our Production for several weeks without any user
> complaints. As always, you should verify yourself too :)
> 
> Regards,
> Billy Richardson

Hello Billy,
can you te(In reply to billy.richardson from comment #24)
> Hey Robert,
> My team and I are in the same position as you.
> 
> I am currently not sending the SameSite cookie attribute to the following
> User Agents:
> 
> ^.*iPhone; CPU iPhone OS 1[0-2].*$
> ^.*iPad; CPU OS 1[0-2].*$
> ^.*iPod touch; CPU iPhone OS 1[0-2].*$
> ^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$
> 
> This has been in place in our Production for several weeks without any user
> complaints. As always, you should verify yourself too :)
> 
> Regards,
> Billy Richardson

Hello,
Billy sent me this response
<If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS X.*Version\x2F1[0-2].*Safari)/i">
    Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</If>

Here is a demo page I setup: https://demo.richardson.dev/safarisamesiteapache/ 

If this helped, please share it with others!

and i have made this one on headers

- edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure env=!BUG_SAME_SITE
    setenvif:
    - User-Agent ^.*iPhone; CPU iPhone OS 1[0-2].*$ BUG_SAME_SITE
    - User-Agent ^.*iPad; CPU OS 1[0-2].*$ BUG_SAME_SITE
    - User-Agent ^.*iPod touch; CPU iPhone OS 1[0-2].*$ BUG_SAME_SITE
    - User-Agent ^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$ BUG_SAME_SITE

[Jay Shaw]

The REGEX doesn't seem to capture Safari 10.14.6

Any fix for this?

[Jay Shaw]

(In reply to achkim from comment #27)
> (In reply to billy.richardson from comment #24)
> > Hey Robert,
> > My team and I are in the same position as you.
> > 
> > I am currently not sending the SameSite cookie attribute to the following
> > User Agents:
> > 
> > ^.*iPhone; CPU iPhone OS 1[0-2].*$
> > ^.*iPad; CPU OS 1[0-2].*$
> > ^.*iPod touch; CPU iPhone OS 1[0-2].*$
> > ^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$
> > 
> > This has been in place in our Production for several weeks without any user
> > complaints. As always, you should verify yourself too :)
> > 
> > Regards,
> > Billy Richardson
> 
> Hello Billy,
> can you te(In reply to billy.richardson from comment #24)
> > Hey Robert,
> > My team and I are in the same position as you.
> > 
> > I am currently not sending the SameSite cookie attribute to the following
> > User Agents:
> > 
> > ^.*iPhone; CPU iPhone OS 1[0-2].*$
> > ^.*iPad; CPU OS 1[0-2].*$
> > ^.*iPod touch; CPU iPhone OS 1[0-2].*$
> > ^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$
> > 
> > This has been in place in our Production for several weeks without any user
> > complaints. As always, you should verify yourself too :)
> > 
> > Regards,
> > Billy Richardson
> 
> Hello,
> Billy sent me this response
> <If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS
> 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS
> X.*Version\x2F1[0-2].*Safari)/i">
>     Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
> </If>
> 
> Here is a demo page I setup:
> https://demo.richardson.dev/safarisamesiteapache/ 
> 
> If this helped, please share it with others!
> 
> and i have made this one on headers
> 
> - edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure env=!BUG_SAME_SITE
>     setenvif:
>     - User-Agent ^.*iPhone; CPU iPhone OS 1[0-2].*$ BUG_SAME_SITE
>     - User-Agent ^.*iPad; CPU OS 1[0-2].*$ BUG_SAME_SITE
>     - User-Agent ^.*iPod touch; CPU iPhone OS 1[0-2].*$ BUG_SAME_SITE
>     - User-Agent ^.*Macintosh; Intel Mac OS X.*Version\/1[0-2].*Safari.*$
> BUG_SAME_SITE

The regex doesn't seem to capture Safari 10.14.6... any fix for this?

[Remko Tronçon]

Heads up: the above regex is incomplete: for OS X, it checks on Safari version only, but this fails for e.g. Safari 13 on OS X 10.14.

[Jay Shaw]

(In reply to Remko Tronçon from comment #30)
> Heads up: the above regex is incomplete: for OS X, it checks on Safari
> version only, but this fails for e.g. Safari 13 on OS X 10.14.

I think this fixes the issue with 10.14:

<If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS X.*Version\x2F1[0-2].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
    Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</If>

[Nadav Ofir]

Seems to still be buggy on OS X 10.15.3 (Safari 13.1) - can you confirm this is not yet shipped? where can we see an ETA if such exists?

[Jay Shaw]

(In reply to Nadav Ofir from comment #32)
> Seems to still be buggy on OS X 10.15.3 (Safari 13.1) - can you confirm this
> is not yet shipped? where can we see an ETA if such exists?

Can you test and let us know if this tweak works for 13.1 as well?:

<If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-2]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-2]|Macintosh; Intel Mac OS X.*Version\x2F1[0-3].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
    Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</If>

[Nadav Ofir]

I used a similar regex in my application, only note that the OS X should be expended to `10_1[4-5]` (since it now happens on OSX 10.15
Allow me to emphasize that, at this moment, I don't have any proof that this is due to the Same-Site bug in Safari. that is just my assumption here.

[Jay Shaw]

(In reply to Nadav Ofir from comment #34)
> I used a similar regex in my application, only note that the OS X should be
> expended to `10_1[4-5]` (since it now happens on OSX 10.15
> Allow me to emphasize that, at this moment, I don't have any proof that this
> is due to the Same-Site bug in Safari. that is just my assumption here.

there are 2 different targets for osx safari in the regex - the first one should work. best to just test the regex supplied and then comment.

[Nadav Ofir]

(In reply to Jay Shaw from comment #35)
> (In reply to Nadav Ofir from comment #34)
> > I used a similar regex in my application, only note that the OS X should be
> > expended to `10_1[4-5]` (since it now happens on OSX 10.15
> > Allow me to emphasize that, at this moment, I don't have any proof that this
> > is due to the Same-Site bug in Safari. that is just my assumption here.
> 
> there are 2 different targets for osx safari in the regex - the first one
> should work. best to just test the regex supplied and then comment.

Jay Shaw - sorry, I didn't notice you added the [0-3] in the former expression.. thanks for that. works as expected now.

[Jay Shaw]

(In reply to Nadav Ofir from comment #36)
> (In reply to Jay Shaw from comment #35)
> > (In reply to Nadav Ofir from comment #34)
> > > I used a similar regex in my application, only note that the OS X should be
> > > expended to `10_1[4-5]` (since it now happens on OSX 10.15
> > > Allow me to emphasize that, at this moment, I don't have any proof that this
> > > is due to the Same-Site bug in Safari. that is just my assumption here.
> > 
> > there are 2 different targets for osx safari in the regex - the first one
> > should work. best to just test the regex supplied and then comment.
> 
> Jay Shaw - sorry, I didn't notice you added the [0-3] in the former
> expression.. thanks for that. works as expected now.


Here's another one with the IPHONE and TOUCH versions updated as well. I believe these have also been updated. I'm sure theres a smarter way to do this, but anyways works for now.

<If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-3]|iPad; CPU OS 1[0-2]|iPod touch; CPU iPhone OS 1[0-3]|Macintosh; Intel Mac OS X.*Version\x2F1[0-3].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
    Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</If>

[Jay Shaw]

(In reply to Jay Shaw from comment #37)
> (In reply to Nadav Ofir from comment #36)
> > (In reply to Jay Shaw from comment #35)
> > > (In reply to Nadav Ofir from comment #34)
> > > > I used a similar regex in my application, only note that the OS X should be
> > > > expended to `10_1[4-5]` (since it now happens on OSX 10.15
> > > > Allow me to emphasize that, at this moment, I don't have any proof that this
> > > > is due to the Same-Site bug in Safari. that is just my assumption here.
> > > 
> > > there are 2 different targets for osx safari in the regex - the first one
> > > should work. best to just test the regex supplied and then comment.
> > 
> > Jay Shaw - sorry, I didn't notice you added the [0-3] in the former
> > expression.. thanks for that. works as expected now.
> 
> 
> Here's another one with the IPHONE and TOUCH versions updated as well. I
> believe these have also been updated. I'm sure theres a smarter way to do
> this, but anyways works for now.
> 
> <If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-3]|iPad; CPU OS
> 1[0-2]|iPod touch; CPU iPhone OS 1[0-3]|Macintosh; Intel Mac OS
> X.*Version\x2F1[0-3].*Safari|Macintosh;.*Mac OS X 10_14.*
> AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
>     Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
> </If>

DOH! I forgot the Ipad version!

<If "%{HTTP_USER_AGENT} !~ /(iPhone; CPU iPhone OS 1[0-3]|iPad; CPU OS 1[0-3]|iPod touch; CPU iPhone OS 1[0-3]|Macintosh; Intel Mac OS X.*Version\x2F1[0-3].*Safari|Macintosh;.*Mac OS X 10_14.* AppleWebKit.*Version\x2F1[0-3].*Safari)/i">
    Header edit Set-Cookie ^(.*)$ $1;SameSite=None;Secure
</If>

[diego pierangeli]

Sorry, but the fix is out?

I've a site with SameSite=NONE that's seems rejected in Safari (Catalina latest).

[John Wilander]

(In reply to diego pierangeli from comment #39)
> Sorry, but the fix is out?
> 
> I've a site with SameSite=NONE that's seems rejected in Safari (Catalina
> latest).

Hi! SameSite=none is not treated as an unknown value and made into SameSite=strict. That change shipped long ago.

In what scenario does your SameSite=none cookie get rejected? Note that Safari blocks all third party cookies, both setting and using. If you need access to cookies as a third party, you need to call the Storage Access API.

[Deniss Kozlovs]

The problem is, "None" should not be treated as "Strict" because they have opposite meanings. "Strict" means that cookie will not be transferred to third-party, and not be transferred back when returning from third-party domain.
"None" means default behavior that existed since 1997.

This now requires a dirty hack (by using regex to parse user agent) to be made when setting session parameters in the backend, because Chrome now requires SameSite=None when using cross-domain redirects back and forth (for example, making payments).

[John Wilander]

(In reply to Deniss Kozlovs from comment #41)
> The problem is, "None" should not be treated as "Strict" because they have
> opposite meanings. "Strict" means that cookie will not be transferred to
> third-party, and not be transferred back when returning from third-party
> domain.
> "None" means default behavior that existed since 1997.
> 
> This now requires a dirty hack (by using regex to parse user agent) to be
> made when setting session parameters in the backend, because Chrome now
> requires SameSite=None when using cross-domain redirects back and forth (for
> example, making payments).

Browsers are allowed to set a cookie policy, i.e. there is no mandate to have cookies be accepted in all cases. The default cookie policies of for example Safari, Firefox, and Chrome all differ.

The default cookie policy in Safari since 2003 has been to not allow third parties without pre-existing cookies to set new cookies. In 2017, Safari shipped Intelligent Tracking Prevention (ITP) which then blocked classified third parties from using cookies. In 2020, ITP was updated to block *all* third party cookies.

Other browsers built on WebKit may have other default cookie policies.

The SameSite=lax by default change was driven by the Chrome team and is not in effect in Safari. SameSite=none support was added to Safari in 2019. SameSite=none is not a way to unblock third party cookies in Safari. If you need access to cookies as a third party in Safari, you need to call the Storage Access API.

[ChristianV]

Does it mean that SPA Applications calling third-party APIs (with proper CORS set-up) that rely on cookies to properly work are broken ?
Something like the drawing to give you an idea.


  abc.com                                                   api.net
                                                           +---------------+
+----------+                                               |               |
|          |  (Ajax Requesto to API)                       |               |
|          | +------------------------------------------>  |               |
|          |  origin: abc.com                              |               |
|          |                                               |               |
|          |  (API Response with Cookie)                   |               |
|          | <-------------------------------------------+ |               |
|          | Access|Control|Allow|Credentials: true        |               |
|          | Access-Control-Allow-Origin: https://abc.com  |               |
|          | Cookie: myCookie ; domain=api.net             |               |
+----------+                                               +---------------+

[John Wilander]

(In reply to ChristianV from comment #43)
> Does it mean that SPA Applications calling third-party APIs (with proper
> CORS set-up) that rely on cookies to properly work are broken ?
> Something like the drawing to give you an idea.
> 
> 
>   abc.com                                                   api.net
>                                                            +---------------+
> +----------+                                               |               |
> |          |  (Ajax Requesto to API)                       |               |
> |          | +------------------------------------------>  |               |
> |          |  origin: abc.com                              |               |
> |          |                                               |               |
> |          |  (API Response with Cookie)                   |               |
> |          | <-------------------------------------------+ |               |
> |          | Access|Control|Allow|Credentials: true        |               |
> |          | Access-Control-Allow-Origin: https://abc.com  |               |
> |          | Cookie: myCookie ; domain=api.net             |               |
> +----------+                                               +---------------+

Hi! The scenario you are describing has never been supported under Safari’s default cookie policy. Between 2003 and 2017, api.net would have to be visited as first party website and set cookies as such before it could use cookies as third party.

Between 2017 and March 2020, if api.net was used under multiple different websites, it would be blocked from third-party cookies even if it had been visited as first party website.

As of March 2020, all third party cookies are blocked unconditionally and the third party needs to call the Storage Access API to ask for the user’s permission to use cookies.

[Andra Ruebsteck]

(In reply to John Wilander from comment #44)
> (In reply to ChristianV from comment #43)
> > Does it mean that SPA Applications calling third-party APIs (with proper
> > CORS set-up) that rely on cookies to properly work are broken ?
> > Something like the drawing to give you an idea.
> > 
> > 
> >   abc.com                                                   api.net
> >                                                            +---------------+
> > +----------+                                               |               |
> > |          |  (Ajax Requesto to API)                       |               |
> > |          | +------------------------------------------>  |               |
> > |          |  origin: abc.com                              |               |
> > |          |                                               |               |
> > |          |  (API Response with Cookie)                   |               |
> > |          | <-------------------------------------------+ |               |
> > |          | Access|Control|Allow|Credentials: true        |               |
> > |          | Access-Control-Allow-Origin: https://abc.com  |               |
> > |          | Cookie: myCookie ; domain=api.net             |               |
> > +----------+                                               +---------------+
> 
> Hi! The scenario you are describing has never been supported under Safari’s
> default cookie policy. Between 2003 and 2017, api.net would have to be
> visited as first party website and set cookies as such before it could use
> cookies as third party.
> 
> Between 2017 and March 2020, if api.net was used under multiple different
> websites, it would be blocked from third-party cookies even if it had been
> visited as first party website.
> 
> As of March 2020, all third party cookies are blocked unconditionally and
> the third party needs to call the Storage Access API to ask for the user’s
> permission to use cookies.

We have a very similar case as ChrisitanV:

  abc.com                                                     api.net
+----------+                                                 +---------------+
|          |  Redirect to login page                         |               |
|          | +---------------------------------------------> |               |
|          |                                                 |               |
|          |  Redirect back with Cookie                      |               |
|          | <---------------------------------------------+ |               |
|          |   Location: https://abc.com                     |               |
|          |   Cookie: myCookie ; domain=api.net             |               |
|          |                                                 |               |
|          |  (Ajax Requesto to API to check login status)   |               |
|          | +---------------------------------------------> |               |
|          |  origin: abc.com                                |               |
|          |  Cookie: myCookie                               |               |
+----------+                                                 +---------------+

Obviously the cookie on the Ajax request is not actually sent to the server under the Intelligent Tracking Prevention.

How can the Storage Access API be used in this case? As I understand it can only be used by content in iFrames (https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API)

[John Wilander]

(In reply to Andra Ruebsteck from comment #45)
> (In reply to John Wilander from comment #44)
> > (In reply to ChristianV from comment #43)
> > > Does it mean that SPA Applications calling third-party APIs (with proper
> > > CORS set-up) that rely on cookies to properly work are broken ?
> > > Something like the drawing to give you an idea.
> > > 
> > > 
> > >   abc.com                                                   api.net
> > >                                                            +---------------+
> > > +----------+                                               |               |
> > > |          |  (Ajax Requesto to API)                       |               |
> > > |          | +------------------------------------------>  |               |
> > > |          |  origin: abc.com                              |               |
> > > |          |                                               |               |
> > > |          |  (API Response with Cookie)                   |               |
> > > |          | <-------------------------------------------+ |               |
> > > |          | Access|Control|Allow|Credentials: true        |               |
> > > |          | Access-Control-Allow-Origin: https://abc.com  |               |
> > > |          | Cookie: myCookie ; domain=api.net             |               |
> > > +----------+                                               +---------------+
> > 
> > Hi! The scenario you are describing has never been supported under Safari’s
> > default cookie policy. Between 2003 and 2017, api.net would have to be
> > visited as first party website and set cookies as such before it could use
> > cookies as third party.
> > 
> > Between 2017 and March 2020, if api.net was used under multiple different
> > websites, it would be blocked from third-party cookies even if it had been
> > visited as first party website.
> > 
> > As of March 2020, all third party cookies are blocked unconditionally and
> > the third party needs to call the Storage Access API to ask for the user’s
> > permission to use cookies.
> 
> We have a very similar case as ChrisitanV:
> 
>   abc.com                                                     api.net
> +----------+                                                
> +---------------+
> |          |  Redirect to login page                         |              
> |
> |          | +---------------------------------------------> |              
> |
> |          |                                                 |              
> |
> |          |  Redirect back with Cookie                      |              
> |
> |          | <---------------------------------------------+ |              
> |
> |          |   Location: https://abc.com                     |              
> |
> |          |   Cookie: myCookie ; domain=api.net             |              
> |
> |          |                                                 |              
> |
> |          |  (Ajax Requesto to API to check login status)   |              
> |
> |          | +---------------------------------------------> |              
> |
> |          |  origin: abc.com                                |              
> |
> |          |  Cookie: myCookie                               |              
> |
> +----------+                                                
> +---------------+
> 
> Obviously the cookie on the Ajax request is not actually sent to the server
> under the Intelligent Tracking Prevention.
> 
> How can the Storage Access API be used in this case? As I understand it can
> only be used by content in iFrames
> (https://developer.mozilla.org/en-US/docs/Web/API/Storage_Access_API)

There needs to be an iframe from api.net under abc.com calling the Storage Access API upon a user gesture in the iframe and the user must have previously interacted with api.net as first party (doesn’t seem like an issue for you since api.net in your case is somewhere where the user logs in) and api.net must have existing cookies.

The Storage Access API is meant for *authenticated embeds*, i.e. embedded cross-site content that needs to authenticate an already logged in user.