No same site = None cookies for iOS18
github.com
github.com
> 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.
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.
```
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.
... and what do you suggest schools (for example) use instead? Bear in mind that "invasive tracking" is also used for protection of the vulnerable.
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.
I don't know what that has to do with cookies though.
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.
[1]: https://developer.mozilla.org/en-US/blog/goodbye-third-party...
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.
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.