Authentication and authorization cookies seem pretty essential for any website that has accounts. If you block those cookies the website stops working -- they're essential.
If you block ad networks and analytics the site functions just fine -- they're not essential.
Beyond that there's probably some sort of "need to know" test to prevent convoluted fake dependencies.
They are not really, really essential. No cookie is essential. A long, long time ago I worked with a web system that kept session info in a URL parameter, and carried it over all the links. I think it was a C# website, but I'm not sure.
I love those systems. Especially when the unwary users share links, accidentally letting other users into the site as them. Or when google indexes it, and in addition to terrible security, the site uses regular GET links to perform site actions, so google deletes the user's content or buys a bunch of stuff as them while walking the links it finds as it indexes in beyond the user's initial account bearing link.
Yes ASP.NET allows (allowed? Haven’t used it in years) cookieless sessions this way. The problem is it has to rewrite all the relative links on the page to ensure session state is not lost.
The problem is it’s makes urls horribly unwieldy if a user wants to bookmark or paste in links from emails etc etc, or writing JS to interact with links, not to mention the security issues of being able to accidentally share your session.
Those were great. I hung around a forum around 2004 where someone posted a link to jeans he just bought from a smallish online store - the URL contained the PHP session identifier. Thousands of people had instant access to his address + bank information + purchase history, and could place orders for him.
Implementing session handling as URL parameters makes no difference from a legal perspective. It will be covered by the law excatly the same as if one used cookies.
It's the tracking the law is about, not the implementation of it.
Your just picking a worse technical solution for no legal gain.
Yes. Some sites operating like that eventually tried to work around this issue by tying it to the IP, but you can see how that is hopelessly broken anyway.
> You won't be able to distinguish device sessions from one another reliably neither. Think of "log out all other devices".
You could, I think. Passing the session ID in the URL is the same as storing it as a cookie. You can invalidate both in the server.
Link sharing is an issue, for sure. You could tie the session id to the IP, but that doesn't work when people share their IP, which is more and more common every day. IP tied session would work better with IPv6, though.
In WAP times there was no such feature as cookies available.
I started programming by writing WML pages instead of HTML. Good memories from those times!
The website at my college we used to register for classes and some other stuff used this method. For whatever reason though, the logic was wonky, and the site would give an error if you used the "back" button in the browser, and you'd have to go back to the home page.
If you block ad networks and analytics the site functions just fine -- they're not essential.
Beyond that there's probably some sort of "need to know" test to prevent convoluted fake dependencies.