3 ms·

Everyone would've emulated cookies using HTML local storage, because it would be a pretty quick fix (just wrap all cookie API's). So you'd gain nothing except p

Everyone would've emulated cookies using HTML local storage, because it would be a pretty quick fix (just wrap all cookie API's). So you'd gain nothing except push people from a standard to an ad hoc solution. Switching to server side storage would've been a too costly architectural change. What if the server side was stateless before? And even if, web applications would still have needed to support the old model for interop reasons. It's not feasible for everyone to maintain code for both approaches when they are so different. It'd also break many use cases, such as using a (signed) cookie as cache for some really frequently used data. Or more importantly authentication, where an auth service returns a token (in some cases a token that can be checked by a different service without contacting the auth service again). So yeah, that was a non starter.

Erlich_Bachman 6y ago
> What if the server side was stateless before? Then that's a pretty bad design choice to begin with? If some state is required for operation, but the website keeps it only on client? Not least of all reasons, for security?
- toast0 6y ago
  You can make such state cookies tamperproof with server side signing. Depending on the state in question, leaving it with the client, instead of in server storage, makes for good lifetime management. Of course, if you want the state to be synced between different clients (for a logged in user or something), you'll need to do something else.
- throwaway3neu94 6y ago
  Statelessness is often a good thing in designs in many ways, performance, reliability, maintainability, operating cost etc. As a concrete example for a common use case, websites show your user or first name in the top right corner. It's common to put this in a cookie set on login/logout. This avoids querying the user directory service (from the frontend or a different backend service) on every pageload. Security wise it doesn't matter if the user tampers with it, it's a display only thing. (More often than not it's signed anyway, and the cookie contains other things as well.) Cookies meant to be presented back to a server can be signed and (optionally) encrypted. This is also a very widely used pattern ("cookie secret" is a good search term for concrete implementations in frameworks).
  - lidHanteyk 6y ago
    You can't have your cookie and eat it, too; the browser has to store profile information or cookie information either way, so this was never about statelessness. This is about the expectation that user agents will not just consent to server tracking, but carry around papers which will identify themselves to each server so that they can be better tracked.
    - throwaway3neu94 6y ago
      I'm sorry if I didn't explain what I meant well enough. I was talking about statelessness on the server side. If you remove cookies from HTTP, you now need a database on the server side. You also get extra communication (between the client/DB, or the web service/DB), whereas previously the data would've already been available in both (the client has the jar, and the web service gets it in each the request). Turning a local memory read into a network request can be a difficult architectural change. Also, DynamoDB reads are priced per unit ;-)

Erlich_Bachman 6y ago

> What if the server side was stateless before? Then that's a pretty bad design choice to begin with? If some state is required for operation, but the website keeps it only on client? Not least of all reasons, for security?

toast0 6y ago
You can make such state cookies tamperproof with server side signing. Depending on the state in question, leaving it with the client, instead of in server storage, makes for good lifetime management. Of course, if you want the state to be synced between different clients (for a logged in user or something), you'll need to do something else.
throwaway3neu94 6y ago
Statelessness is often a good thing in designs in many ways, performance, reliability, maintainability, operating cost etc. As a concrete example for a common use case, websites show your user or first name in the top right corner. It's common to put this in a cookie set on login/logout. This avoids querying the user directory service (from the frontend or a different backend service) on every pageload. Security wise it doesn't matter if the user tampers with it, it's a display only thing. (More often than not it's signed anyway, and the cookie contains other things as well.) Cookies meant to be presented back to a server can be signed and (optionally) encrypted. This is also a very widely used pattern ("cookie secret" is a good search term for concrete implementations in frameworks).
- lidHanteyk 6y ago
  You can't have your cookie and eat it, too; the browser has to store profile information or cookie information either way, so this was never about statelessness. This is about the expectation that user agents will not just consent to server tracking, but carry around papers which will identify themselves to each server so that they can be better tracked.
  - throwaway3neu94 6y ago
    I'm sorry if I didn't explain what I meant well enough. I was talking about statelessness on the server side. If you remove cookies from HTTP, you now need a database on the server side. You also get extra communication (between the client/DB, or the web service/DB), whereas previously the data would've already been available in both (the client has the jar, and the web service gets it in each the request). Turning a local memory read into a network request can be a difficult architectural change. Also, DynamoDB reads are priced per unit ;-)