Hacker News Reader

Comment by level3 | Hacker News Reader

The way it was done before without cookies was including the user's session ID as a query parameter in the URL. Adding things to your cart was also done through query parameters.

It was later realized that session IDs in the URL led to lots of security problems, but it's possible we would've come up with ways to mitigate those if cookies hadn't become widespread.

View on HN

Preferring only POST form submissions vs GET links might have helped some, with proxies perhaps, while previous implementations of “disabled cookies” functionality in early forum software would tie the session ID to other information known about your session, such as your IP address and browser identifier, and often there was a time-out for your session identifier that would reset every time you visited another page on the site. Thus somewhat limiting how easily you could share your session accidentally with someone else in multiple ways. Today this would be less practical as folks switch from wifi to cellular frequently. And it was still a “workaround” even then, the preference for developers was still to use a session cookie where available for simplicity. (Annoyingly, the session cookie historically often came with the same IP address and browser user agent matching restrictions though this wouldn’t be as necessary given the different technology employed.)

I do recall that in early implementations of cookies in web browsers, they were disabled by default. But when a website wanted to set a cookie, a prompt would appear. Actually, this might have just been the configuration of some of the shared computers I was using at the time at school and in other places.

https://dl.acm.org/doi/10.1145/365024.365034 has a number of screenshots from early browsers, Netscape 1-4 and IE 3-5. All had cookies enabled by default, apparently.

I might be thinking of the cookies prompts in Links and Lynx text mode browsers, as I tended to use those more often back then over dialup. The cookie prompts in general were terrible because you never knew what part of the site would be enabled or disabled before interacting with the site. To that end, Safari’s approach is quite reasonable for a default.

Someone would have ended up inventing some X-Session-Id HTTP header that the server would send to the user agent, and the user-agents supporting the "HTTP Sessions extension" would send back a X-Session-Id with the same content to the same origin. A special empty value would have been used to terminate the session, from the client or from the server.

Another HTTP header, X-Session-Expiration, would have been added to expire sessions.

I was going to suggest that ?x-private-*= or ?s= URL query parameters could not be copied/pasted /s ;-)

I imagine the page would need to also use some sort of dictionary-based compression for efficient transfer of the page if it has many links on it. ;-)

On the plus side, you wouldn’t need megabytes of cookies...

Reply on news.ycombinator.com