7 ms·

This "book" does not work without JS enabled. Disappointingly, out of all of the changes in HTTP/3, cookies are still present. It'd be nice if HTTP/4 weren't a

This "book" does not work without JS enabled. Disappointingly, out of all of the changes in HTTP/3, cookies are still present. It'd be nice if HTTP/4 weren't also a continuation of Google entrenching its tracking practices into the Web's structure and protocols.

api 8y ago
Cookies date back to the late 1990s, and it's relatively easy for browsers to implement anti-tracking features that block cookies except for their respective sites and block cross-site tracking cookies. Firefox and Safari have features like this. Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's.
- m0dest 8y ago
  >Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's. citation needed
- epc 8y ago
  If you think of 1994 as late 1990s, sure. Cookies have been around almost as long as the web proper, and vilified for about the same amount of time.
snazz 8y ago
I’m not a web developer, so sorry for the dumb question, but how would you possibly do authentication (the login on this site, for instance) without cookies or something that’s functionally equivalent?
- duiker101 8y ago
  Haven't seen it in a long time but websites used to keep the session id in the query string
  - snazz 8y ago
    Wouldn’t that make the session key show up in log files on the server and on any network infrastructure between the server and the client?
    - ams6110 8y ago
      Assuming https, the querystring is encrypted, so should be safe in transit. Could show up in server logs though, I'd think. The server can log a lot of things though, depending how it's configured.
      - Ndymium 8y ago
        Session ID in URL is a terrible idea because guess what, people share links with each other. Example: A school enrollment system in Finland logs you on with another person's account if they give you the link to a page they are viewing (which they often do), because the session is in the query string.
  - krferriter 8y ago
    That's a bad idea because it is visible on the UI and anywhere the user copies/saves the URL, and it would also still have all the downsides that cookie-based tracking enables. Cookies are how HTTP application sessions work, it isn't possible to just get rid of them, without replacing them with something identical in functionality even if you change the name.
- codezero 8y ago
  Its possible to do this on the server side. Form submissions don’t require JavaScript, and authentication post submission can be done with cookies. Or if you want to go way back http basic auth. To be clear: I support JavaScript on the web, just hoping to answer your question. Also sorry: I answered the wrong question. Http basic with would still work. I remember a time when basic auth gave you a unique url and the referrer was used to validate you. This was easy to break because you can fake the referrer.
  - nicoburns 8y ago
    > authentication post submission can be done with cookies I think the comment you are replying to is reacting to the top-level comment which is advocating removing cookies.
    - codezero 8y ago
      Yep. My bad.
  - nickdandakis 8y ago
    I think the parent meant authentication persistence, without cookies.
Jonnax 8y ago
JavaScript is part of the web. Developers shouldn't have to cater for an incredibly small percentage of people that don't enable it.
- aaaaaaaaaaab 8y ago
  You must have said the same about ActiveX fifteen years ago.
  - collyw 8y ago
    That was IE only though.
    - ams6110 8y ago
      Which comprised 90% of the browsers in use.
- 3xblah 8y ago
  No need to enable it. It is on by default. :) If it were off by default, would web developers cater to the incredibly small percentage of people who change default settings to turn it on? Why is there even a setting? How many people would ever want to turn Javascript off? When they provide a setting to toggle Javascript are browser developers catering to an incredibly small percentage of people? How many people use it?
  - marcosdumay 8y ago
    Those people making sites that are completely broken without javascript have very precise numbers to look at showing that approximately none of their repeating visitors disable javascript. We, by the other side, have no unbiased number to look and discover if it's a common behavior ;)
    - 3xblah 8y ago
      I reckon the key word in this comment is "approximately". I might still be able to get what I need from a site that someone believes is "completely broken", including on repeat visits, without using Javascript. Sometimes HN commenters debate what it means when a site "does not work" without Javascript. Some believe if an HTTP request can retrieve the content, then the site works. Others believe if the content of the site is not displayed as the author intended then the site is not "working". I would bet that the definition of "completely broken" could vary as well. Do the people running sites try to determine how many users are actually using Javascript to make the requests, e.g., to some endpoint that serves the content, maybe a CDN? Browser authors could in theory include some "telemetry" in their software that reports back to Mozilla, Google, Microsoft, Apple, etc. when a user has toggled Javascript on or off. Maybe it could be voluntarily reported by the user in the form of opt-in "diagnostics". OTOH, what can people making sites do to distinguish if a GET or POST accompanied by all the correct headers sent to a content server came from a browser with Javascript enabled or whether it was sent with Javascript off or by using some software that does not interpret Javascript? The content server just returns content, e.g., JSON. It may distinguish a valid request from an invalid one, but how does it accurately determine whether the http client is interpreting Javascript? If a user were to use Developer Tools and make the request from a custom http client that has no JS engine, can/do they measure that? Regardless of how easy or difficult it would be to reliably determine whether a client making a request is interpreting Javascript (i.e. more than simply looking at headers or network behaviour), the question is how many people making sites are doing that? They can more easily just assume (correctly, no doubt) that few users are emulating favoured browsers rather than actually using them. One might imagine they could have a bias toward assuming that the number of such users is small, even if it wasn't. :)
anc84 8y ago
It does not load any third-party content though which in my book, counts as a +10 on the "does not work with JS disabled" scale.
jimmy1 8y ago
Out of all the web storage methods, cookies are still the most reliable and secure to implement sessions. I for one am glad they are not going anywhere.
- takeda 8y ago
  Cookies are a hack to implement sessions. If http/2 and now http/3 would go for real innovation, we would replace cookies with proper sessions, like PHK suggested: https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0172.html https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep...
3xblah 8y ago
# lang={en,fr,ja,zh} https://daniel.haxx.se/http3-explained/details.html https://daniel.haxx.se/http3-explained/details.html https://legacy.gitbook.com/download/pdf/book/bagder/http3-explained?lang=en https://legacy.gitbook.com/download/pdf/book/bagder/http3-ex... https://legacy.gitbook.com/download/mobi/book/bagder/http3-explained?lang=en https://legacy.gitbook.com/download/mobi/book/bagder/http3-e... https://legacy.gitbook.com/download/epub/book/bagder/http3-explained?lang=en https://legacy.gitbook.com/download/epub/book/bagder/http3-e...
tfolbrecht 8y ago
It's also been rendered in ePub, Mobi, and PDF https://legacy.gitbook.com/book/bagder/http3-explained/details https://legacy.gitbook.com/book/bagder/http3-explained/detai...
vszakats 8y ago
The book can be downloaded in pdf/e-book formats (and multiple languages) from: https://daniel.haxx.se/http3-explained/ https://daniel.haxx.se/http3-explained/
camccar 8y ago
looks like it was made with mdBook https://github.com/rust-lang-nursery/mdBook https://github.com/rust-lang-nursery/mdBook
- steveklabnik 8y ago
  I don’t believe so. mdBook is a port of gitbook, and I believe it was made with that.

api 8y ago

Cookies date back to the late 1990s, and it's relatively easy for browsers to implement anti-tracking features that block cookies except for their respective sites and block cross-site tracking cookies. Firefox and Safari have features like this. Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's.

m0dest 8y ago
>Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's. citation needed
epc 8y ago
If you think of 1994 as late 1990s, sure. Cookies have been around almost as long as the web proper, and vilified for about the same amount of time.

snazz 8y ago

I’m not a web developer, so sorry for the dumb question, but how would you possibly do authentication (the login on this site, for instance) without cookies or something that’s functionally equivalent?

duiker101 8y ago
Haven't seen it in a long time but websites used to keep the session id in the query string
- snazz 8y ago
  Wouldn’t that make the session key show up in log files on the server and on any network infrastructure between the server and the client?
  - ams6110 8y ago
    Assuming https, the querystring is encrypted, so should be safe in transit. Could show up in server logs though, I'd think. The server can log a lot of things though, depending how it's configured.
    - Ndymium 8y ago
      Session ID in URL is a terrible idea because guess what, people share links with each other. Example: A school enrollment system in Finland logs you on with another person's account if they give you the link to a page they are viewing (which they often do), because the session is in the query string.
- krferriter 8y ago
  That's a bad idea because it is visible on the UI and anywhere the user copies/saves the URL, and it would also still have all the downsides that cookie-based tracking enables. Cookies are how HTTP application sessions work, it isn't possible to just get rid of them, without replacing them with something identical in functionality even if you change the name.
codezero 8y ago
Its possible to do this on the server side. Form submissions don’t require JavaScript, and authentication post submission can be done with cookies. Or if you want to go way back http basic auth. To be clear: I support JavaScript on the web, just hoping to answer your question. Also sorry: I answered the wrong question. Http basic with would still work. I remember a time when basic auth gave you a unique url and the referrer was used to validate you. This was easy to break because you can fake the referrer.
- nicoburns 8y ago
  > authentication post submission can be done with cookies I think the comment you are replying to is reacting to the top-level comment which is advocating removing cookies.
  - codezero 8y ago
    Yep. My bad.
- nickdandakis 8y ago
  I think the parent meant authentication persistence, without cookies.

Jonnax 8y ago

JavaScript is part of the web. Developers shouldn't have to cater for an incredibly small percentage of people that don't enable it.

aaaaaaaaaaab 8y ago
You must have said the same about ActiveX fifteen years ago.
- collyw 8y ago
  That was IE only though.
  - ams6110 8y ago
    Which comprised 90% of the browsers in use.
3xblah 8y ago
No need to enable it. It is on by default. :) If it were off by default, would web developers cater to the incredibly small percentage of people who change default settings to turn it on? Why is there even a setting? How many people would ever want to turn Javascript off? When they provide a setting to toggle Javascript are browser developers catering to an incredibly small percentage of people? How many people use it?
- marcosdumay 8y ago
  Those people making sites that are completely broken without javascript have very precise numbers to look at showing that approximately none of their repeating visitors disable javascript. We, by the other side, have no unbiased number to look and discover if it's a common behavior ;)
  - 3xblah 8y ago
    I reckon the key word in this comment is "approximately". I might still be able to get what I need from a site that someone believes is "completely broken", including on repeat visits, without using Javascript. Sometimes HN commenters debate what it means when a site "does not work" without Javascript. Some believe if an HTTP request can retrieve the content, then the site works. Others believe if the content of the site is not displayed as the author intended then the site is not "working". I would bet that the definition of "completely broken" could vary as well. Do the people running sites try to determine how many users are actually using Javascript to make the requests, e.g., to some endpoint that serves the content, maybe a CDN? Browser authors could in theory include some "telemetry" in their software that reports back to Mozilla, Google, Microsoft, Apple, etc. when a user has toggled Javascript on or off. Maybe it could be voluntarily reported by the user in the form of opt-in "diagnostics". OTOH, what can people making sites do to distinguish if a GET or POST accompanied by all the correct headers sent to a content server came from a browser with Javascript enabled or whether it was sent with Javascript off or by using some software that does not interpret Javascript? The content server just returns content, e.g., JSON. It may distinguish a valid request from an invalid one, but how does it accurately determine whether the http client is interpreting Javascript? If a user were to use Developer Tools and make the request from a custom http client that has no JS engine, can/do they measure that? Regardless of how easy or difficult it would be to reliably determine whether a client making a request is interpreting Javascript (i.e. more than simply looking at headers or network behaviour), the question is how many people making sites are doing that? They can more easily just assume (correctly, no doubt) that few users are emulating favoured browsers rather than actually using them. One might imagine they could have a bias toward assuming that the number of such users is small, even if it wasn't. :)

anc84 8y ago

It does not load any third-party content though which in my book, counts as a +10 on the "does not work with JS disabled" scale.

jimmy1 8y ago

Out of all the web storage methods, cookies are still the most reliable and secure to implement sessions. I for one am glad they are not going anywhere.

takeda 8y ago
Cookies are a hack to implement sessions. If http/2 and now http/3 would go for real innovation, we would replace cookies with proper sessions, like PHK suggested: https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0172.html https://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep...

3xblah 8y ago

# lang={en,fr,ja,zh} https://daniel.haxx.se/http3-explained/details.html https://daniel.haxx.se/http3-explained/details.html https://legacy.gitbook.com/download/pdf/book/bagder/http3-explained?lang=en https://legacy.gitbook.com/download/pdf/book/bagder/http3-ex... https://legacy.gitbook.com/download/mobi/book/bagder/http3-explained?lang=en https://legacy.gitbook.com/download/mobi/book/bagder/http3-e... https://legacy.gitbook.com/download/epub/book/bagder/http3-explained?lang=en https://legacy.gitbook.com/download/epub/book/bagder/http3-e...

tfolbrecht 8y ago

It's also been rendered in ePub, Mobi, and PDF https://legacy.gitbook.com/book/bagder/http3-explained/details https://legacy.gitbook.com/book/bagder/http3-explained/detai...

vszakats 8y ago

The book can be downloaded in pdf/e-book formats (and multiple languages) from: https://daniel.haxx.se/http3-explained/ https://daniel.haxx.se/http3-explained/

camccar 8y ago

looks like it was made with mdBook https://github.com/rust-lang-nursery/mdBook https://github.com/rust-lang-nursery/mdBook

steveklabnik 8y ago
I don’t believe so. mdBook is a port of gitbook, and I believe it was made with that.