5 ms·

Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially

by robomc 12y ago

Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).

organsnyder 12y ago
I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.
phkamp 12y ago
It's really very simple: Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits. In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie. If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session. If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you. Of course this can be abused, but not nearly as much as cookies are abused today. But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.
- jchrisa 12y ago
  It also forces the session to be tracked on the server. Many apps use cookies to keep the session in the browser. Maybe deprecating the document.cookie API so that people move to local storage, is a good first step? More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
- a_dutch_guy 12y ago
  (Without being pedantic) are you aware of MinimaLT? It is really interesting technology (UDP).
- robomc 12y ago
  Seems like anything a server could do via cookies, they could also do via your client-generated session id. Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id. If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.
  - Vendan 12y ago
    Well, yeah, for a basic implementation, it's rather easy to track like that. What about a system where the unique id returned is based on a random value hashed with the domain name of the window? Then third party trackers would get a different id from you on each site, but your sessions would be static on the site.
    - robomc 12y ago
      True it would make it difficult to do third-party tracking across multiple sites (unless there was server-side information connecting your accounts, like an email address). And leaving aside browser fingerprinting. That could also just by achieved by disallowing third party cookies though - feels on the cusp of being a browser implementation problem (just stop allowing third party cookies).
- a_dutch_guy 12y ago
  This is the link to MinimaLT (it runs on top of UDP instead of TCP). As of today I haven't seen an implementation and MinimaLT being a paper there are some ambiguous parts, but overall this looks like a really well defined spec. It tackles at least the cookie issue. It supports tunneling and it deals with DOS. The other real benefit is that it is RPC based, which means that the protocol is easy to extend (think about NFS and SSH alternatives) and maybe it could be the foundation of a new HTTP. AFAIK it doesn't deal with the CA certs / trust issue. http://www.ethos-os.org/~solworth/minimalt-20131031.pdf http://www.ethos-os.org/~solworth/minimalt-20131031.pdf

by robomc 12y ago

organsnyder 12y ago

I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.

phkamp 12y ago

It's really very simple: Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits. In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie. If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session. If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you. Of course this can be abused, but not nearly as much as cookies are abused today. But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.

jchrisa 12y ago
It also forces the session to be tracked on the server. Many apps use cookies to keep the session in the browser. Maybe deprecating the document.cookie API so that people move to local storage, is a good first step? More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
a_dutch_guy 12y ago
(Without being pedantic) are you aware of MinimaLT? It is really interesting technology (UDP).
robomc 12y ago
Seems like anything a server could do via cookies, they could also do via your client-generated session id. Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id. If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.
- Vendan 12y ago
  Well, yeah, for a basic implementation, it's rather easy to track like that. What about a system where the unique id returned is based on a random value hashed with the domain name of the window? Then third party trackers would get a different id from you on each site, but your sessions would be static on the site.
  - robomc 12y ago
    True it would make it difficult to do third-party tracking across multiple sites (unless there was server-side information connecting your accounts, like an email address). And leaving aside browser fingerprinting. That could also just by achieved by disallowing third party cookies though - feels on the cusp of being a browser implementation problem (just stop allowing third party cookies).
a_dutch_guy 12y ago
This is the link to MinimaLT (it runs on top of UDP instead of TCP). As of today I haven't seen an implementation and MinimaLT being a paper there are some ambiguous parts, but overall this looks like a really well defined spec. It tackles at least the cookie issue. It supports tunneling and it deals with DOS. The other real benefit is that it is RPC based, which means that the protocol is easy to extend (think about NFS and SSH alternatives) and maybe it could be the foundation of a new HTTP. AFAIK it doesn't deal with the CA certs / trust issue. http://www.ethos-os.org/~solworth/minimalt-20131031.pdf http://www.ethos-os.org/~solworth/minimalt-20131031.pdf