|
|
|
|
|
|
by bob1029
1055 days ago
|
|
|
We have been able to happily side-step this entire conversation in our new web properties. We literally use zero cookies (local storage, et. al.) in our latest products. The user's state is entirely managed on the server, and we pass their session identifier forward through hidden form fields or URL query parameter as appropriate. The only way this works is to go all-in on SSR-style web applications. 100% of user interactions must be satisfied with boring-ass form get/post. The microsecond you start thinking about SPA or holding onto even the merest of boolean facts between page loads, the whole magic experience vanishes in an instant. That isn't to say you can't use javascript, but you certainly don't start with it. Our initial reasoning for going to this extent was due to weird behavior around cookie lifetime we were seeing on iOS/safari devices as of iOS13. If you don't use any client-side state, other than what is loaded into the current window/document/URL, who could ever ruin your day? They'd literally have to cripple 100% of the internet to start causing trouble for our newest approach. Over time, it became obvious this style also provides a better user & development experience. For instance, I no longer have to put the Apple WWDC event on my work calendar in anticipation of a refactoring effort. Pending legislation is also something I do not worry about anymore. I find it interesting that the most compliant web experience is also the easiest (aka most boring) to develop and also usually provides the best end user experience. To me, cookie banners ultimately seem to be a higher order consequence of splitting the product into front-end/back-end and farming out every possible consideration to a 3rd party. |
|
|