Besides using session cookies, they can track user agent and IP address. The two in combination will be unique enough. There are further metrics to make a unique identifier, but I think this is sufficient explanation.
Edit: Seems like people who don’t know how to program besides super default methods are downvoting me.
You don’t need cookies to hold session ID. If you programmed in the earlier days, you’d actually even know cookie session wasn’t even the most common method before. For example, session ID can be passed around in the URL as another query parameter. You can even literally turn off cookie option in sessions in languages like PHP (ex: https://www.php.net/manual/en/session.configuration.php#ini.session.use-cookies). These kind of practice is still relatively quite common as it allows greater flexibility and not have your session ID bound to a domain.
Furthermore, you don’t have to be restricted by the confines of whatever existing tools you already have. Like in the example I gave at the beginning, you can create your own unique identifiers. You don’t have to use preexisting concept of session at all. If you can create any unique key-value pair, you can track and keep data without the use of sessions. Programmers are hired to create things that never existed before, be more creative.
Either you store it in a cookie which the browser passes to the server for you, or you store it in a url parameter and you (or your html / temp laying Generation framework, or some JavaScript manipulation) needs to ensure all links or other server calls like POST, will need to include that session ID passed back to the server.
And this talk about IP addresses is complete nonsense because of Proxies and NAT and a ton of other reasons. You can attempt to use it in combination with a session ID, but you certainly cannot use that alone.
Actually for most people, the browser sends enough information in the headers, ignoring cookies, to identify them as unique. You can check out an experiment about this at https://www.amiunique.org/fingerprint. Combining that with an ip gets you pretty close.
Well that’s still a form of session ID. But you are saying things like “most people” and “pretty close”, so it’s not a very good session ID, since it’s not guaranteed to be unique.
First of all, this comment chain is about being able to keep tabs on someone without storing information locally on the user’s computer. If we create a new form of session ID equivalent that doesn’t store information locally, I have achieved the goal to the problem that was raised. The issue wasn’t whether or not we needed concept of something equivalent to a session ID.
[…] will need to include that session ID passed back to the server.
Yes, that’s exactly what we used to do in the '00s. Look at softwares like osCommerce v1 and 2. We literally put money behind this method of tracking.
And this talk about IP addresses is complete nonsense because of Proxies and NAT and a ton of other reasons. You can attempt to use it in combination with a session ID, but you certainly cannot use that alone.
Yes, you can use that alone. Without session ID. The other commenter already addressed why this isn’t true. Also context matters. Pretty close is a good enough of a session ID replacement for purpose of tracking whether or not they consented to the cookie policy. If I did a concat of IP, and various fingerprints (and put a hash on it to make it shorter), I can easily reach one in trillion probabilities. I wouldn’t build a secure military website on it because it’s easily forgeable, but it’s more than enough for cookie policy popup.
Depends on how the site is written to handle it. There’s plenty of shopping carts, for instance, that do this. Other stuff, too. Here’s a discussion of how it can be done with PHP on the server side. There’s other options, as well.
And how does the server know which session was yours?
Besides using session cookies, they can track user agent and IP address. The two in combination will be unique enough. There are further metrics to make a unique identifier, but I think this is sufficient explanation.
Edit: Seems like people who don’t know how to program besides super default methods are downvoting me.
You don’t need cookies to hold session ID. If you programmed in the earlier days, you’d actually even know cookie session wasn’t even the most common method before. For example, session ID can be passed around in the URL as another query parameter. You can even literally turn off cookie option in sessions in languages like PHP (ex: https://www.php.net/manual/en/session.configuration.php#ini.session.use-cookies). These kind of practice is still relatively quite common as it allows greater flexibility and not have your session ID bound to a domain.
Furthermore, you don’t have to be restricted by the confines of whatever existing tools you already have. Like in the example I gave at the beginning, you can create your own unique identifiers. You don’t have to use preexisting concept of session at all. If you can create any unique key-value pair, you can track and keep data without the use of sessions. Programmers are hired to create things that never existed before, be more creative.
No, a cookie with a session ID is stored by the client.
I see you’re not familiar with the concept of a rhetorical question.
no
Session ID is stored by the client. So…? I literally just explained how to hold uniqueness on server side without using session ID.
Tbf you still have a session ID.
Either you store it in a cookie which the browser passes to the server for you, or you store it in a url parameter and you (or your html / temp laying Generation framework, or some JavaScript manipulation) needs to ensure all links or other server calls like POST, will need to include that session ID passed back to the server.
And this talk about IP addresses is complete nonsense because of Proxies and NAT and a ton of other reasons. You can attempt to use it in combination with a session ID, but you certainly cannot use that alone.
Actually for most people, the browser sends enough information in the headers, ignoring cookies, to identify them as unique. You can check out an experiment about this at https://www.amiunique.org/fingerprint. Combining that with an ip gets you pretty close.
Well that’s still a form of session ID. But you are saying things like “most people” and “pretty close”, so it’s not a very good session ID, since it’s not guaranteed to be unique.
First of all, this comment chain is about being able to keep tabs on someone without storing information locally on the user’s computer. If we create a new form of session ID equivalent that doesn’t store information locally, I have achieved the goal to the problem that was raised. The issue wasn’t whether or not we needed concept of something equivalent to a session ID.
Yes, that’s exactly what we used to do in the '00s. Look at softwares like osCommerce v1 and 2. We literally put money behind this method of tracking.
Yes, you can use that alone. Without session ID. The other commenter already addressed why this isn’t true. Also context matters. Pretty close is a good enough of a session ID replacement for purpose of tracking whether or not they consented to the cookie policy. If I did a concat of IP, and various fingerprints (and put a hash on it to make it shorter), I can easily reach one in trillion probabilities. I wouldn’t build a secure military website on it because it’s easily forgeable, but it’s more than enough for cookie policy popup.
The point is that it’s a cookie.
Depends on how the site is written to handle it. There’s plenty of shopping carts, for instance, that do this. Other stuff, too. Here’s a discussion of how it can be done with PHP on the server side. There’s other options, as well.
https://stackoverflow.com/questions/42379157/can-sessions-work-without-cookies-if-so-how-does-a-session-work-without-cookie
More info:
https://www.w3schools.com/php/php_sessions.asp