3 ms·

> we'd be left with basic auth over https. That's equivalent to a first party cookie. It would be enough to create an ecommerce site with a cart not exactly. a

by thayne 7y ago

> we'd be left with basic auth over https. That's equivalent to a first party cookie. It would be enough to create an ecommerce site with a cart not exactly. a site can't set basic auth for you, which means you would have to log in before adding something to your cart. whereas with cookies, you can add to your cart before having to authenticate in any way. Now, as long as javascript is enabled, there are other ways to handle that, such as local storage. But that is relatively recent.

level3 7y ago
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.
- jraph 7y ago
  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. /s
  - lstamour 7y ago
    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...
- lstamour 7y ago
  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 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.
eqvinox 7y ago
> a site can't set basic auth for you That probably would've been added... ... and then we'd have essentially a single cookie per domain with wholly different higher-level semantics (user control through a password manager.) That ... actually sounds preferable?
e12e 7y ago
> not exactly. a site can't set basic auth for you, http://username:password@example.com http://username:password@example.com Not sure if that works via 301/302 redirects - I think it might - but most/all browsers warn that there's a username/password in the url?

by thayne 7y ago

level3 7y ago

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.

jraph 7y ago
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. /s
- lstamour 7y ago
  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...
lstamour 7y ago
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 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.

eqvinox 7y ago

> a site can't set basic auth for you That probably would've been added... ... and then we'd have essentially a single cookie per domain with wholly different higher-level semantics (user control through a password manager.) That ... actually sounds preferable?

e12e 7y ago

> not exactly. a site can't set basic auth for you, http://username:password@example.com http://username:password@example.com Not sure if that works via 301/302 redirects - I think it might - but most/all browsers warn that there's a username/password in the url?