There problem is when your auto-detection gets it wrong and you keep getting served the mobile version even if you are not (looking at you www.arista.com).
This is a good use of a session cookie. Or even a stored cookie.
It would be considered a non-tracking essential site function value too, so you wouldn't need to beg permission (contrary to what people who want us to be against privacy legislation will claim), and the site is probably already asking for permission anyway for other reasons so even that point is moot.
I was meaning non-tracking essential cookies, as defined by privacy legislation that requires permission for things that are not essential for site features.
Or are you suggesting mainstream browsers are blocking same-origin session-level cookies by default now? I'm not aware of any. And if you have a browser that is blocking such things, the worst that will happen is the current behaviour (repeated mis-guesses because the preference isn't stored) continues.
This is not entirely accurate. It's only script-writable storage. HTTP cookies are not removed.
I'm not defending Safari's policy, by the way, just describing. I think it sucks, and a conspiracy theorist might note how it favors native apps over web apps.
Needing to re-override the incorrectly detected mobile/not upon return after a full week away will be massively less annoying than needing to do it every new page request, so that shouldn't be problematical.
That Safari does this is useful information that I may need to warn users of one of my projects about, as it means intentionally offline data has a much shorter expiry date than on other platforms.
Everything you've not visited in the last seven days, yes.
Things you touch regularly should be fine.
And apparently it only affects mass local storage, not cookies which are most often used for season management (so you might stay logged in but the app need to reset data previously called in local storage).
how would a cookie help with better auto-detection? to store the platform, maybe, but how do you determine whether the user wants a mobile/desktop version to begin with?
It doesn't help the detection, it means that the override when the detection fails is remembered so the site knows to just pick a particular version instead of using the detection method at all.
It is a work-around improving the UX on the second and subsequent requests, not a fix for the root cause.
If you do it right you don't have auto-detection because you don't have separate versions of the page in the first place. CSS is powerful enough to adapt a page to whatever viewport it happens to be displayed on.
"Remove .m. subdomain, serve mobile and desktop variants through the same URL" https://phabricator.wikimedia.org/T214998