4 ms·

But what about preferences for anonymous users? Store that on the server side? Append them to the URL? Both options kinda suck. Also, consider dabblet. The way

But what about preferences for anonymous users? Store that on the server side? Append them to the URL? Both options kinda suck. Also, consider dabblet. The way it allows you to store your stuff using github is very smart IMHO.

phkamp 14y ago
Store it on the server: The user-agent gives you a session-id to use as key. It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim to have a clear opinion of yet.
- duckharp 14y ago
  Store the settings of anyone who ever connected? For how long? Forever, just in case? Silly. And why do you even assume the server has to have a database? Why should it be required to have one, why should it have to store the stuff? What is your take on statelessness? you concentrate so much on the abuses of cookies and client side storage/computation, but you're not addressing the advantages. I doubt you're aware of them to be honest.
  - phkamp 14y ago
    Uhm, isn't that how it works today ? Do you care about how many metric shitloads of storage your cookies take up on client's disks ? Shouldn't you ? Putting the cost of storage where the decision to store is made is sound economic practics.
    - papsosouid 14y ago
      It is the user's session data. If it is stored on their end, they can choose how long they wish to store it for, and delete it any time they like.
    - comex 14y ago
      My Cookies directory is 11 MB. That's actually quite a lot, considering the length of the average cookie, but my disk is 256 GB and it's only gotten that big because I've been browsing for years literally without ever clearing my cookies and I can clear them at any time. This is really a non-issue.
- ay 14y ago
  User-agent, and other bits of stuff that is duly noted by http://panopticlick.eff.org/ http://panopticlick.eff.org/ are much-much-much worse than cookies. Cookies you can erase. User-agent and other "fingerprints" are with you forever. And they travel with you no matter where you are. So, while you would dismiss the "privacy hazard" that the cookies are, you replace it with something much worse.
  - sophacles 14y ago
    You can still have the cookie concept, and have the session id be a random number each time someone sends a tab to the site. The cookie can hold those preferences, and the session id can be used for session stuff. As a bonus, you can then only load the cookie on the first page load, and keep the values in cache associated with the browser random session number, saving in data transfer issues, and losing nothing. And for those that don't need cookies, they get a big win in terms of privacy.
    - ay 14y ago
      ok, so I grpk the idea correctly it is something like "send the cookie-like-data from the client only on the first GET, if you are doing it over HTTP/1.1 single TCP connection" - that sense (and could be easily made into an extension to HTTP/1.1 - [though it creates the dependency between the different GET requests] - have the server will just send "X-Dont-Send-Me-More-Cookies-in-this-TCP: yes!" header from the server, and make the compliant clients react to it). What I do not understand where's the win on the privacy front here. You send the random ids - but the site owner will re-correlate these random IDs with your identity. So, you would not win anything here - or, what am I missing ? My take on the privacy: There is no problem with someone collecting a bunch of info about me and using it to improve their services. There is a little bit of a problem with someone collecting a bunch of info about me and another million people and keeping that in a big blob. There is a big problem when that someone gets hacked and this bunch of info about another million people gets to the bad kids. It's the centralization of a lot of data that is bad for the privacy. Store the data locally on the clients and give it to the server only when it is contextually needed. e.g.: my shipping address, I am happy for my browser to supply it to you from my local storage to you every time you want to ship me something. I am very happy if you do not store and sell this address to someone who will later send snail-mail spam to me. Or store without the due diligence ('cos time to market and all that) and then get hacked and then I find myself "having paid" for the helicopter spare parts. Of course, this would hurt the nouveau business models that treat the users as a product. And will make the analytics harder - because one would not be able to just run a select... But to me it could be a useful tradeoff. (above, I use the term "client" to refer to the collective set of the devices that are "mine". As I wrote in another reply, storing the state on client does not imply the difference in the user-seen behavior, so the shopping cart should survive).

phkamp 14y ago

Store it on the server: The user-agent gives you a session-id to use as key. It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim to have a clear opinion of yet.

duckharp 14y ago
Store the settings of anyone who ever connected? For how long? Forever, just in case? Silly. And why do you even assume the server has to have a database? Why should it be required to have one, why should it have to store the stuff? What is your take on statelessness? you concentrate so much on the abuses of cookies and client side storage/computation, but you're not addressing the advantages. I doubt you're aware of them to be honest.
- phkamp 14y ago
  Uhm, isn't that how it works today ? Do you care about how many metric shitloads of storage your cookies take up on client's disks ? Shouldn't you ? Putting the cost of storage where the decision to store is made is sound economic practics.
  - papsosouid 14y ago
    It is the user's session data. If it is stored on their end, they can choose how long they wish to store it for, and delete it any time they like.
  - comex 14y ago
    My Cookies directory is 11 MB. That's actually quite a lot, considering the length of the average cookie, but my disk is 256 GB and it's only gotten that big because I've been browsing for years literally without ever clearing my cookies and I can clear them at any time. This is really a non-issue.
ay 14y ago
User-agent, and other bits of stuff that is duly noted by http://panopticlick.eff.org/ http://panopticlick.eff.org/ are much-much-much worse than cookies. Cookies you can erase. User-agent and other "fingerprints" are with you forever. And they travel with you no matter where you are. So, while you would dismiss the "privacy hazard" that the cookies are, you replace it with something much worse.
- sophacles 14y ago
  You can still have the cookie concept, and have the session id be a random number each time someone sends a tab to the site. The cookie can hold those preferences, and the session id can be used for session stuff. As a bonus, you can then only load the cookie on the first page load, and keep the values in cache associated with the browser random session number, saving in data transfer issues, and losing nothing. And for those that don't need cookies, they get a big win in terms of privacy.
  - ay 14y ago
    ok, so I grpk the idea correctly it is something like "send the cookie-like-data from the client only on the first GET, if you are doing it over HTTP/1.1 single TCP connection" - that sense (and could be easily made into an extension to HTTP/1.1 - [though it creates the dependency between the different GET requests] - have the server will just send "X-Dont-Send-Me-More-Cookies-in-this-TCP: yes!" header from the server, and make the compliant clients react to it). What I do not understand where's the win on the privacy front here. You send the random ids - but the site owner will re-correlate these random IDs with your identity. So, you would not win anything here - or, what am I missing ? My take on the privacy: There is no problem with someone collecting a bunch of info about me and using it to improve their services. There is a little bit of a problem with someone collecting a bunch of info about me and another million people and keeping that in a big blob. There is a big problem when that someone gets hacked and this bunch of info about another million people gets to the bad kids. It's the centralization of a lot of data that is bad for the privacy. Store the data locally on the clients and give it to the server only when it is contextually needed. e.g.: my shipping address, I am happy for my browser to supply it to you from my local storage to you every time you want to ship me something. I am very happy if you do not store and sell this address to someone who will later send snail-mail spam to me. Or store without the due diligence ('cos time to market and all that) and then get hacked and then I find myself "having paid" for the helicopter spare parts. Of course, this would hurt the nouveau business models that treat the users as a product. And will make the analytics harder - because one would not be able to just run a select... But to me it could be a useful tradeoff. (above, I use the term "client" to refer to the collective set of the devices that are "mine". As I wrote in another reply, storing the state on client does not imply the difference in the user-seen behavior, so the shopping cart should survive).