4 ms·

I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption

I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.

numbsafari 12y ago
You can begin today to do away with cookies on your own sites and services. Start implementing richer clients and leveraging Open ID Connect and OAuth2. Cookies solve real use case problems. Unless we all start building and experiencing and improving the alternatives, progress won't be made. That said, good luck on getting rid of cookies all together.
- ecthiender 12y ago
  Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.
  - MichaelGG 12y ago
    HTML5 has local storage, so you can put auth tokens in there and only send them when you need them, versus on every request.
    - stephenr 12y ago
      So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?
      - omeid2 12y ago
        "Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.
        stephenr 12y ago
        > "Applications" on the web are inherently dependant on JavaScript No, they are not.
        omeid2 12y ago
        Then we clearly have different definition of "application". For me, an web application runs in the browser, not merely exposes an API over HTTP that can be used by HTML from a browser.
        stephenr 12y ago
        You have a very narrow definition of an application then.
        omeid2 12y ago
        Please elaborate.
        marrs 12y ago
        Absolutely. I'm sick and tired of idiot developers fucking up the web with their bullshit "apps" which are slow, crash all the time, and break everything. I've worked on more "web apps" than I can count and the reality is, only 2 of them were legitimate use cases for a pure JS solution. And we gain nothing from it. I've just spent all morning debugging an issue with a complicated angular directive (and not for the first time) that would have been a few lines of jquery a couple of years ago. Probably because a bored dev wanted to play with a new toy. As you imply, we were writing sophisticated web apps long before AJAX was popularised and those apps were way more reliable and predictable than what we have now, and they worked in Lynx if you wanted.
      - ecthiender 12y ago
        I agree with you completely. Cookies are an older technology and is well supported in all kinds of browser. Plus it does the client side of session management for you(sending the tokens on every request). Localstorage is newer technology and might not be feasible in all situations. Plus JS+XHR are also not available to all kinds of users. (People using Tor, NoScript etc). Also, I don't see the advantage of storing session/auth tokens in localstorage over cookies. Both are stored in plain text, and can be read if somehow it is obtained. Also, using localstorage means writing your own client-side implementation of doing the session management. I also don't see the advantage of using session tokens in URLs. Anyway cookies are included as part of header of the HTTP request, you don't have to have your application send session trackers. I think both are functionally same and the tokens in URLs just does not look good! And public/private key-based signing system is still not there yet, unless we simplify some UX issues about having private/public keys for every user, we are not getting there. So, it looks like, to me, there is no really effective alternative for doing sessions apart from cookies (even in HTTP/2)?!
    - keeperofdakeys 12y ago
      Maybe you can get around not using cookies for an AJAX application that keeps a constant connection open. But for the other 99% of the web, you still need cookies to get the statefullness required for any kind of authentication or tracking. Cookies aren't auth tokens anyway, just session trackers.
  - hueving 12y ago
    You can carry the session ID in the URL. This also has the benefit of eliminating XSRF. The downside is that you have a horrendous URL if that type if thing bothers you, and you can't have a "remember me" check box in your login.
    - amatix 12y ago
      This approach has some massive downsides - the session ID is sent via Referer to outbound links, URLs are logged all over the place (including browser histories), it's easy for people to publicly share it without thinking which then ends up in Google as well...
    - al2o3cr 12y ago
      Partying like it's LITERALLY 1999...
    - lutoma 12y ago
      That's a horrible suggestion, it's not 1999 anymore…
  - blueskin_ 12y ago
    Theoretically, we could move to a private key based system, where your browser encrypts/signs with a private key for each site, but there's neither the will to do it, nor the means to make it simple for the room temperature IQs. Shame, as the privacy and security benefits would be amazing.
    - stephenr 12y ago
      This could be done today with TLS Client Certificates. There is already browser support (through either <KeyGen /> or the MS alternative, which is an API rather than an element, I believe) for creating a private/public key pair, and sending the public key to the server. Unfortunately it's not fantastically simple to move to a new device (particularly not a mobile device where client certs are even harder to install)
- blueskin_ 12y ago
  >richer clients Please, no. The internet works because it's compatible, and installing a local client for everything just prevents use of a service.
cespare 12y ago
It's unfortunate that TLS ended up being optional in HTTP/2, but if the big browsers only support HTTP/2 over TLS (as FF/Chrome have said they will do) then we might see very little non-TLS deployment.

I wish instead of a protocol improvement that focused solely on network resources, the next version will also include improvements for users such as encryption by default and doing away with cookies.

numbsafari 12y ago

You can begin today to do away with cookies on your own sites and services. Start implementing richer clients and leveraging Open ID Connect and OAuth2. Cookies solve real use case problems. Unless we all start building and experiencing and improving the alternatives, progress won't be made. That said, good luck on getting rid of cookies all together.

ecthiender 12y ago
Excuse my ignorance, but how can I do session management without using cookies? I tried searching on the net, but it doesn't seem to give any concrete/valid results. Can you give me any pointers? Edit: I do use OAuth2.0 on my services and use Mozilla Persona to manage user logins, but I am not clear how can I keep sessions between requests if I don't use cookies.
- MichaelGG 12y ago
  HTML5 has local storage, so you can put auth tokens in there and only send them when you need them, versus on every request.
  - stephenr 12y ago
    So rather than just using cookies effectively, you can make your application absolutely dependant on both JavaScrip and XHR?
    - omeid2 12y ago
      "Applications" on the web are inherently dependant on JavaScript and most often XHR too, but I do agree that using Local Storage has little to no advantage over Cookies.
      - stephenr 12y ago
        > "Applications" on the web are inherently dependant on JavaScript No, they are not.
        omeid2 12y ago
        Then we clearly have different definition of "application". For me, an web application runs in the browser, not merely exposes an API over HTTP that can be used by HTML from a browser.
        stephenr 12y ago
        You have a very narrow definition of an application then.
        omeid2 12y ago
        Please elaborate.
        marrs 12y ago
        Absolutely. I'm sick and tired of idiot developers fucking up the web with their bullshit "apps" which are slow, crash all the time, and break everything. I've worked on more "web apps" than I can count and the reality is, only 2 of them were legitimate use cases for a pure JS solution. And we gain nothing from it. I've just spent all morning debugging an issue with a complicated angular directive (and not for the first time) that would have been a few lines of jquery a couple of years ago. Probably because a bored dev wanted to play with a new toy. As you imply, we were writing sophisticated web apps long before AJAX was popularised and those apps were way more reliable and predictable than what we have now, and they worked in Lynx if you wanted.
    - ecthiender 12y ago
      I agree with you completely. Cookies are an older technology and is well supported in all kinds of browser. Plus it does the client side of session management for you(sending the tokens on every request). Localstorage is newer technology and might not be feasible in all situations. Plus JS+XHR are also not available to all kinds of users. (People using Tor, NoScript etc). Also, I don't see the advantage of storing session/auth tokens in localstorage over cookies. Both are stored in plain text, and can be read if somehow it is obtained. Also, using localstorage means writing your own client-side implementation of doing the session management. I also don't see the advantage of using session tokens in URLs. Anyway cookies are included as part of header of the HTTP request, you don't have to have your application send session trackers. I think both are functionally same and the tokens in URLs just does not look good! And public/private key-based signing system is still not there yet, unless we simplify some UX issues about having private/public keys for every user, we are not getting there. So, it looks like, to me, there is no really effective alternative for doing sessions apart from cookies (even in HTTP/2)?!
  - keeperofdakeys 12y ago
    Maybe you can get around not using cookies for an AJAX application that keeps a constant connection open. But for the other 99% of the web, you still need cookies to get the statefullness required for any kind of authentication or tracking. Cookies aren't auth tokens anyway, just session trackers.
- hueving 12y ago
  You can carry the session ID in the URL. This also has the benefit of eliminating XSRF. The downside is that you have a horrendous URL if that type if thing bothers you, and you can't have a "remember me" check box in your login.
  - amatix 12y ago
    This approach has some massive downsides - the session ID is sent via Referer to outbound links, URLs are logged all over the place (including browser histories), it's easy for people to publicly share it without thinking which then ends up in Google as well...
  - al2o3cr 12y ago
    Partying like it's LITERALLY 1999...
  - lutoma 12y ago
    That's a horrible suggestion, it's not 1999 anymore…
- blueskin_ 12y ago
  Theoretically, we could move to a private key based system, where your browser encrypts/signs with a private key for each site, but there's neither the will to do it, nor the means to make it simple for the room temperature IQs. Shame, as the privacy and security benefits would be amazing.
  - stephenr 12y ago
    This could be done today with TLS Client Certificates. There is already browser support (through either <KeyGen /> or the MS alternative, which is an API rather than an element, I believe) for creating a private/public key pair, and sending the public key to the server. Unfortunately it's not fantastically simple to move to a new device (particularly not a mobile device where client certs are even harder to install)
blueskin_ 12y ago
>richer clients Please, no. The internet works because it's compatible, and installing a local client for everything just prevents use of a service.

cespare 12y ago

It's unfortunate that TLS ended up being optional in HTTP/2, but if the big browsers only support HTTP/2 over TLS (as FF/Chrome have said they will do) then we might see very little non-TLS deployment.