Hacker News Reader

Comment by deepstack | Hacker News Reader

web pages do NOT need cookies or javascript period.

and if you insist on that your users must use javascript to view your web site, then cookie is not even needed, one can do some finger printing and there is your permanent cookie!

This development of web has many tech savvy people stop using internet on their phone and switched back to old dump phones (and this comes from someone who has being promoting JS since before nodejs came along). Please bring back web pages that does not require cookie or javascript to function, a web page that can work in the terminal browser like lynx or links2 is the base standard for web page. JS and cookies are just icing on the cake not needed.

View on HN

Web pages don't need javascript? Get real. You have to use javascript for your web app if you want to deliver a reasonable product experience. This is a dead argument I wish people would just stop making. The ship sailed over a decade ago.

You can have a really really good experience with how using JavaScript, but it does have very genuine uses.

The vast majority of the web really honestly doesn't need it though, like this website.

Without cookies - and knowing that HTTP is a stateless protocol - how do you suggest we implement a solution that allows me to connect on my bank to view my account balance and make a wire transfer from the comfort of my home ?

The way we did that kind of thing before cookies was by encoding the state in the URL (for GET requests) or hidden fields (for POST). Higher-level Web frameworks at the time would often abstract this away from the app code while allowing the app to be deployed in either mode. Here's an example for ASP.NET: https://docs.microsoft.com/en-us/dotnet/api/system.web.confi...

If you encode auth token in the URL then a shared URL accidental or otherwise means being authenticated. There is a lot of existing infrastructure that assumes the URL is public knowledge while cookies are not.

If you do this through hidden forms then page navigation can no longer be done through hyperlinks and must now all be form submissions, which means a malfunctioning back button and logout when refreshing or opening a link in a new tab.

Please do not do this.

First party cookies are very useful and it's bad enough that people keep trying to replace them with javascript+localstorage despite the decades of security best practices that have been built into them.

I do agree that we can do away with third party cookies however.

FWIW I'm not suggesting that people do any of this today. But it is how it was actually done - it wasn't the case that advanced web apps that required per-client state management weren't possible at all without cookies.

exactly! web developer in the late 90's did that and worked fine. Yeah it is a bit more pain to use, however it keeps web stateless which was a what it suppose to be. If you want to make your fancy desktop stateful programs do it with something that is not document base like html.

It didn't keep the web stateless, though. It implemented state on top of what we had at the time, with certain flaws that others have already pointed out in this thread.

I worked on framerworks like this. Heck, I built a (horrible, internal only) one once.

The issue with this was that it broke direct linking to pages, or created such ugly and long URLs that they were weren't "sharing" friendly.

It was horrible, and cookies were (and remain) a much better solution.

You could do that using TLS client certificates, but they have terrible UX that browser vendors are only making worse over time.

There are also other auth mechanisms natively supported by browsers, like HTTP Basic Auth that can be used.

Basic authentication ?

that is fine. It is how user suppose to login to an authenticated area.

I'd rather not throw the cool internet baby out with the ad tech bathwater, thanks.

I always wonder what specifically marked the turning point for web usability. Too many dark UX patterns, popups, ads and extremely heavy frameworks for extremely simple sites.

I feel that we got to a point where the community put out a couple recipes for deploying websites and everyone just jumped on it irrespective of the problem, mimicked the same patterns (email newsletter popups, ads, google analytics, 30 million external assets, etc) and called it a day.

While I think your opinion is a bit extreme, I agree that there are so many things that we don’t need, but companies are hiring and new devs are copying the recipes.

> I always wonder what specifically marked the turning point for web usability. Too many dark UX patterns, popups, ads and extremely heavy frameworks for extremely simple sites.

It's funny that you include popups in that, because actual popups are almost nonexistent today, whereas they were ubiquitous in the early 2000s web.

The web is SO much more usable now than at anytime earlier.

For example, browsers used to actually allow pop-up windows (as in it would open a new desktop window (not a tab), sometimes off-screen). And then when you closed it the browser would let it spawn more pages.

There was a common pattern of spamming popup windows with a "close" button the same place a "run" button was when you downloaded an executable in Windows 95.

And then after closing 10 windows with the button in the same place they'd hit you with an executable download.

This was common.

I agree and I remember those days. However, I think there is a distinction between browser improvements vs web usability.

I’m moreso talking about _how_ people design sites for the web and how poor design choices lead to poor usability. I think the proliferation of tools that require not too much in-depth knowledge (react), heavy CSS frameworks and large client side JS libs have ruined a lot of the web surfing I used to enjoy

Cookies are actually incredibly valuable as a place to store web auth tokens where JavaScript cannot get access to your valuable user information.

No matter what happens, if I store my JWT in a no JavaScript cookie, it's safe. Nowhere else on the web is safe in that way.

I also feel like it's a mistake too Tell people to use fingerprinting instead of cookies, when users actually have control of cookies, it's almost always better for them If we use them instead of fingerprinting.

Outside of fraud and security mitigation I have yet to see a legitimate use case for fingerprinting.

I very much do want the bank to fingerprint the hell out of my devices, front page of my local newspaper? Nope.

How about using browser-supported auth mechanisms instead of manually reimplementing auth using cookies? There is HTTP basic auth, or TLS client certs and probably more.

Basic Auth with digests has some issues, but both that and client certs mostly fail because of poor browser implementation.

Client certs would really be ideal if browsers handled them better and sync'd the certs between devices (like bookmarks), but I guess that still wouldn't solve the signing in from a new/different (non-synced) device.

You could offer one-time rescue codes (like the ones used when people have TOTP auth) to let people add new certs on new devices.

Because both of them work terribly.

I've used basic auth in production. It has terrible user experience, and unfixable issues and limitations.

I wish browser-integrated logins had taken off, with Persona, but that was unfortunately abandoned.

Why are browser vendors so terrible at auth stuff :(

Not just HTTP-only cookies (no JS), but also the control for 'Secure' (HTTPS only) and 'SameSite' for CSRF blocking. Not using cookies and storing your auth tokens in other places is a rookie mistake.

That said, 3rd-party cookies should be blocked by default. IDPs and other exceptional cases can request permission or use one-time query param hashes to exist without them.

JavaScript there are some serious discussions to be had, but cookies are a very nice way of adding state to HTTP.

Reply on news.ycombinator.com