> iOS 18 does not allow a client application to specify SameSite=None
That’s quite a different thing from the present submitted title, “No same site = None cookies for iOS18”, which would suggest SameSite=None was being blocked altogether.
Glancing through, it reads more like “when SameSite default was changed from None to Lax [which everyone else did four years ago, if I recall correctly], there was a bug because the default was actually assumed in one other place that we missed, so that setting SameSite to None in a particular way didn’t work, and this pull request fixes that”. Simple bug, nothing to see here. But I’m not in Apple’s ecosystem, don’t trust my two-minute glance to be accurate and please correct me when I’m wrong.
I first thought it was broken English for "If it's not the same site, then no cookies are allowed", where I thought "same site" means the origin of the cookie and the one that reads it.
- WebKit is honoring the cookie's SameSite=None attribute when the cookie is set by server in this case the IdP
- Attempts to set this attribute from the client side (from the app interacting with the iOS cookie store) have been unsuccessful. For example, by setting `.sameSitePolicy = "none"`
- Safari Web Inspector shows the option to set the cookie's SameSite attribute to None, it however, does not get honored either, and is immediately reverted.
Single sign on works just fine without third-party cookies.
You forward the user to the SSO system with some URL parameters, the SSO system checks the first-party cookies (as the SSO system's domain is shown in the URL bar), then the SSO system forwards the user back to you with some different URL parameters. It can also be done with a popup login window, in many cases.
After all, what if the SSO system needed to ask for the user's password? Your users should know better than to enter their password on a third party's domain - so you need the forwarding mechanism for SSO login anyway.
Schools can use MDM profiles to track or restrict navigation.
Not only would you _not_ want to do it at this level or by setting cookies from a technical perspective, it wouldn’t work well as soon as a user goes to different app.
> Bear in mind that "invasive tracking" is also used for protection of the vulnerable.
If we're going to go down the "think of the children" path, I'd argue invasive tracking is used far more often for persecuting the vulnerable. But anyway, if you want an ultra locked-down machine for schools running Apple devices, use MDM, Santa or whatever else, and network filtering like everyone else.
I'm getting very tired of the idea that we need to bend to ad agencies and absurd government abuse in the supposed name of protecting the innocent. It's suffocating for everyone.
Some people online are strange and scary no doubt; I know that better than anyone. But kids will be kids, and they'll do dangerous things without you knowing; people go home and talk to strangers on Discord or whatever else all day and no amount of browser fingerprinting is going to change that.
Maybe I am the crazy one, though, I don't know. But I only learned to program because I wasn't caged up; I couldn't have been older than six years old or so when my friend introduced me to this MMO, RuneScape, which I became obsessed with. And like all dumb kids, I eventually tried to look for cheats, of course, there were none, but I stumbled upon some reverse engineering forums where people were collaborating and trying to build their own server emulators for the game. It was interesting, so I stuck around, and it incrementally forced me to learn just about everything I could really need -- from software to things like "oh gosh, we've suddenly got players, but now we're getting slammed by some dude's botnet; I am twelve and BlackLotus wants $500 a month for a server with any sort of DDoS mitigation, so we need to figure out how to deal with this on our own".
I had good times, and I had many terrifying times, but at the end of the day, my life would be entirely different if I grew up sheltered and shackled to an iPad with no way to truly investigate the things that interested me. I'm very glad I stole my mom's PowerBook to stay up all night in the vBulletin shoutbox with people no sane person would normally want their child hanging around.
It's part of the no more third party cookies thing and not iOS specific.
Scenario where this matters: If you do Login based on sessions + cookies (eg. Django's default authentication method) you won't be able to have the backend and frontend on different domains or the same domain, but different ports.
Specifically in a local dev scenario, you might have your backend on localhost:8000 and frontend on localhost:4200, you could auth your frontend and backend by allowing the browser to send the cookie between them via the cookie setting `SameSite = None` (Ignoring a couple of browser security details around CSRF, HTTPOnly Cookies and HTTPs requirements).
This is will soon not be possible anymore and in the local dev scenario you need to access both frontend and backend from the same port, by combining them with a HTTP reverse proxy or hosting the frontend files via the backend. This extends to real deployments and affects session + cookie based authentication in a couple of ways, depending on infrastructure.
My experience with SameSite equal None was to move it to Lax. Why? Because when a link in an email client is clicked and opens a site, the cookies are not sent.
For example, you sign up to a website (A). You get a verify email sent to your inbox. You open your inbox (site B) and click the link. The link opens (A) but you're not logged in automatically upon verification, you get logged out because the cookie wasn't sent (since you're coming from B).
Because you were introducing exploits in your "SSO flow" in 2005. You can't have your cake and eat it too. If you want organizations (that spend billions on, and make this software free of cost) to care about security, there will usually be a slight inconvenience penalty you have to pay to comply with better patterns.
Actual title (emphasis mine):
> iOS 18 does not allow a client application to specify SameSite=None
That’s quite a different thing from the present submitted title, “No same site = None cookies for iOS18”, which would suggest SameSite=None was being blocked altogether.
Glancing through, it reads more like “when SameSite default was changed from None to Lax [which everyone else did four years ago, if I recall correctly], there was a bug because the default was actually assumed in one other place that we missed, so that setting SameSite to None in a particular way didn’t work, and this pull request fixes that”. Simple bug, nothing to see here. But I’m not in Apple’s ecosystem, don’t trust my two-minute glance to be accurate and please correct me when I’m wrong.
I first thought it was broken English for "If it's not the same site, then no cookies are allowed", where I thought "same site" means the origin of the cookie and the one that reads it.
[dead]
You're correct, the bug is nothing more than some inconsistencies following the change of SameSite default from None to Lax.
From a user perspective, isn't it an improvement of privacy of iOS users?
The bug report referenced in this issue is the case of invasive tracking (basically enterprise spyware) breaking in iOS18 https://bugs.webkit.org/show_bug.cgi?id=279153
Normal web usage is not affected.
```
- WebKit is honoring the cookie's SameSite=None attribute when the cookie is set by server in this case the IdP
- Attempts to set this attribute from the client side (from the app interacting with the iOS cookie store) have been unsuccessful. For example, by setting `.sameSitePolicy = "none"`
- Safari Web Inspector shows the option to set the cookie's SameSite attribute to None, it however, does not get honored either, and is immediately reverted.
```
The bug you referenced was about single-sign-on. Not sure how did you jump from there to spyware
Single sign on works just fine without third-party cookies.
You forward the user to the SSO system with some URL parameters, the SSO system checks the first-party cookies (as the SSO system's domain is shown in the URL bar), then the SSO system forwards the user back to you with some different URL parameters. It can also be done with a popup login window, in many cases.
After all, what if the SSO system needed to ask for the user's password? Your users should know better than to enter their password on a third party's domain - so you need the forwarding mechanism for SSO login anyway.
"is the case of invasive tracking (basically enterprise spyware)"
... and what do you suggest schools (for example) use instead? Bear in mind that "invasive tracking" is also used for protection of the vulnerable.
Schools can use MDM profiles to track or restrict navigation.
Not only would you _not_ want to do it at this level or by setting cookies from a technical perspective, it wouldn’t work well as soon as a user goes to different app.
It’s used for protection of the companies, so they can’t be held liable. Don’t kid yourself.
What companies do you think are held liable when students look at porn on a school computer?
I don't know what that has to do with cookies though.
What do you mean by “schools” and “protection of vulnerable”?
> Bear in mind that "invasive tracking" is also used for protection of the vulnerable.
If we're going to go down the "think of the children" path, I'd argue invasive tracking is used far more often for persecuting the vulnerable. But anyway, if you want an ultra locked-down machine for schools running Apple devices, use MDM, Santa or whatever else, and network filtering like everyone else.
I'm getting very tired of the idea that we need to bend to ad agencies and absurd government abuse in the supposed name of protecting the innocent. It's suffocating for everyone.
Some people online are strange and scary no doubt; I know that better than anyone. But kids will be kids, and they'll do dangerous things without you knowing; people go home and talk to strangers on Discord or whatever else all day and no amount of browser fingerprinting is going to change that.
Maybe I am the crazy one, though, I don't know. But I only learned to program because I wasn't caged up; I couldn't have been older than six years old or so when my friend introduced me to this MMO, RuneScape, which I became obsessed with. And like all dumb kids, I eventually tried to look for cheats, of course, there were none, but I stumbled upon some reverse engineering forums where people were collaborating and trying to build their own server emulators for the game. It was interesting, so I stuck around, and it incrementally forced me to learn just about everything I could really need -- from software to things like "oh gosh, we've suddenly got players, but now we're getting slammed by some dude's botnet; I am twelve and BlackLotus wants $500 a month for a server with any sort of DDoS mitigation, so we need to figure out how to deal with this on our own".
I had good times, and I had many terrifying times, but at the end of the day, my life would be entirely different if I grew up sheltered and shackled to an iPad with no way to truly investigate the things that interested me. I'm very glad I stole my mom's PowerBook to stay up all night in the vBulletin shoutbox with people no sane person would normally want their child hanging around.
What is being blocked by this that would protect the vulnerable in a school?
Think of the children :'(
Does anyone have more context? Is this part of the general effort to not use third party cookies[1] or is this something more ios specific?
[1]: https://developer.mozilla.org/en-US/blog/goodbye-third-party...
It's part of the no more third party cookies thing and not iOS specific.
Scenario where this matters: If you do Login based on sessions + cookies (eg. Django's default authentication method) you won't be able to have the backend and frontend on different domains or the same domain, but different ports.
Specifically in a local dev scenario, you might have your backend on localhost:8000 and frontend on localhost:4200, you could auth your frontend and backend by allowing the browser to send the cookie between them via the cookie setting `SameSite = None` (Ignoring a couple of browser security details around CSRF, HTTPOnly Cookies and HTTPs requirements).
This is will soon not be possible anymore and in the local dev scenario you need to access both frontend and backend from the same port, by combining them with a HTTP reverse proxy or hosting the frontend files via the backend. This extends to real deployments and affects session + cookie based authentication in a couple of ways, depending on infrastructure.
My experience with SameSite equal None was to move it to Lax. Why? Because when a link in an email client is clicked and opens a site, the cookies are not sent.
For example, you sign up to a website (A). You get a verify email sent to your inbox. You open your inbox (site B) and click the link. The link opens (A) but you're not logged in automatically upon verification, you get logged out because the cookie wasn't sent (since you're coming from B).
It was quite disruptive to basic flows.
Oh boy i'm getting headaches again about SSO flows. How comes web development was easier back in 2005 than in 2024?
Because you were introducing exploits in your "SSO flow" in 2005. You can't have your cake and eat it too. If you want organizations (that spend billions on, and make this software free of cost) to care about security, there will usually be a slight inconvenience penalty you have to pay to comply with better patterns.
Security and privacy