News for hackers. Stuff that matters.
Re:HTTP/3 explained by DaiHafVaho on Tuesday February 05, 2019 @09:59AM (#19085800)
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.

Re:HTTP/3 explained by Jonnax on Tuesday February 05, 2019 @10:08AM (#19085883)
JavaScript is part of the web. Developers shouldn't have to cater for an incredibly small percentage of people that don't enable it.
Re:HTTP/3 explained by johnisgood on Tuesday February 05, 2019 @12:07PM (#19087212)
JavaScript for this particular website is overkill, in my humble opinion. Just because it is part of the web, it does not necessarily mean it should be abused. I especially dislike websites that send me JavaScript-only, even when the site is almost completely static.
Re:HTTP/3 explained by wenc on Tuesday February 05, 2019 @12:27PM (#19087383)
JavaScript complaints on HN are often unproductive and irrelevant to the discussion at hand. I wonder how we can disincentivize such comments.
Re:HTTP/3 explained by hiimnate on Tuesday February 05, 2019 @12:44PM (#19087537)
If Javascript were required to read the HN comments, then anti-js people wouldn't be able to comment, and the fights would never start.

/s

Re:HTTP/3 explained by 3xblah on Tuesday February 05, 2019 @10:44AM (#19086296)
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?

Re:HTTP/3 explained by marcosdumay on Tuesday February 05, 2019 @11:42AM (#19086947)
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 ;)

Re:HTTP/3 explained by 3xblah on Tuesday February 05, 2019 @07:51PM (#19091669)
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. :)

Re:HTTP/3 explained by codedokode on Tuesday February 05, 2019 @02:29PM (#19088831)
> Why is there even a setting? How many people would ever want to turn Javascript off?

Because without JS pages load much faster and browser takes less memory. Ad and tracking often doesn't work without JS. Why would anyone want to use JS?

Re:HTTP/3 explained by 3xblah on Tuesday February 05, 2019 @08:06PM (#19091762)
To extend the functionality of the browser.

What you say is true, so the question is why is it on and not off by default?

Does it imply that a webpage without Javascript is not useful?

Re:HTTP/3 explained by krferriter on Tuesday February 05, 2019 @11:43AM (#19086957)
It's on by default because it is very useful. Just become some websites abuse the ability to run active content doesn't mean Javascript shouldn't be an integral part of the modern web. Browsers should allow the user to crack down on the abuse, but expecting sites to cater to people who disable Javascript is a bit far.
[dead]
Re:HTTP/3 explained by collyw on Tuesday February 05, 2019 @10:21AM (#19086046)
That was IE only though.
Re:HTTP/3 explained by ams6110 on Tuesday February 05, 2019 @10:46AM (#19086322)
Which comprised 90% of the browsers in use.
Re:HTTP/3 explained by jimmy1 on Tuesday February 05, 2019 @10:13AM (#19085948)
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.
Re:HTTP/3 explained by takeda on Tuesday February 05, 2019 @01:14PM (#19087936)
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...
Re:HTTP/3 explained by snazz on Tuesday February 05, 2019 @10:04AM (#19085841)
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?
Re:HTTP/3 explained by duiker101 on Tuesday February 05, 2019 @10:08AM (#19085895)
Haven't seen it in a long time but websites used to keep the session id in the query string
Re:HTTP/3 explained by krferriter on Tuesday February 05, 2019 @11:46AM (#19086984)
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.
Re:HTTP/3 explained by snazz on Tuesday February 05, 2019 @10:36AM (#19086194)
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?
Re:HTTP/3 explained by ams6110 on Tuesday February 05, 2019 @10:49AM (#19086366)
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.
Re:HTTP/3 explained by Ndymium on Tuesday February 05, 2019 @10:57AM (#19086471)
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.
Re:HTTP/3 explained by codezero on Tuesday February 05, 2019 @10:09AM (#19085903)
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.

Re:HTTP/3 explained by nickdandakis on Tuesday February 05, 2019 @10:16AM (#19085987)
I think the parent meant authentication persistence, without cookies.
Re:HTTP/3 explained by nicoburns on Tuesday February 05, 2019 @10:14AM (#19085965)
> 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.

Re:HTTP/3 explained by codezero on Tuesday February 05, 2019 @10:25AM (#19086089)
Yep. My bad.
Re:HTTP/3 explained by tfolbrecht on Tuesday February 05, 2019 @10:16AM (#19085979)
It's also been rendered in ePub, Mobi, and PDF https://legacy.gitbook.com/book/bagder/http3-explained/detai...
Re:HTTP/3 explained by anc84 on Tuesday February 05, 2019 @10:11AM (#19085916)
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.
Re:HTTP/3 explained by vszakats on Tuesday February 05, 2019 @10:16AM (#19085988)
The book can be downloaded in pdf/e-book formats (and multiple languages) from: https://daniel.haxx.se/http3-explained/
Re:HTTP/3 explained by camccar on Tuesday February 05, 2019 @10:41AM (#19086254)
looks like it was made with mdBook https://github.com/rust-lang-nursery/mdBook
Re:HTTP/3 explained by steveklabnik on Tuesday February 05, 2019 @11:17AM (#19086679)
I don’t believe so. mdBook is a port of gitbook, and I believe it was made with that.
Re:HTTP/3 explained by api on Tuesday February 05, 2019 @10:02AM (#19085828)
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.
Re:HTTP/3 explained by epc on Tuesday February 05, 2019 @10:50AM (#19086379)
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.

Re:HTTP/3 explained by m0dest on Tuesday February 05, 2019 @10:25AM (#19086090)
>Don't know about Chrome, but it's likely that Chrome blocks other peoples tracking in favor of Google's.

citation needed