3 ms·

Why isn't an identifier included in each request ("a cookie") not a valid way to track state across requests? It's the solution that makes sense with an otherw

Why isn't an identifier included in each request ("a cookie") not a valid way to track state across requests? It's the solution that makes sense with an otherwise stateless interaction. With a persistent connection, you don't need to send that with each interaction, but the RIP:RPORT:LIP:LPORT tuple becomes the "cookie" that identifies the client or session. > That still leaves us with the problem of Cookies. ... But, if I could avoid having every website yelling at me about using cookies, I'd happily adopt a Websocket architecture, if that's what it took. This is a red herring. If "the problem with cookies" is that websites yell at you about using cookies, that's a legal issue with the requirement to notify users they are being tracked. This "problem" of being yelled at didn't exist before the legal requirement. Moving the transport to websockets (layered on top of HTTP, layered on top of TCP) doesn't get rid of the legal requirement for notification or opt-out. It just buys some time until the law catches up and says that the state management you're using with websockets is also subject to tracking notification and opt-out.

dynamite-ready 6y ago
This is an aside, but to my mind, when necessary (when you're storing user data) devs should be transparent about how that data is stored. Websockets won't necessarily mean you avoid persisting state on the browser. In fact, you'll probably find you'll need to store some tokens on the client, somehow, just to secure the client/server connection.
mbreese 6y ago
> This is a red herring. ... that's a legal issue with the requirement to notify users they are being tracked It’s not a red herring. And it’s not the website warnings that are the issue, it’s the tracking that they have to notify you about. If we didn’t have to allow cookies for basic interactions with websites (like a session cookie), then we wouldn’t need to allow tracking cookies at all. However, because we need to allow session cookies, other sites can then track us. With a persistent connection/session, this wouldn’t be necessary. But clearly, there are many other ways to tackle this problem. And the persistent socket connection also has issues. But after thinking about this, I think the company behind the current dominant browser may be a little conflicted about solving this issue. I’m hopeful about Firefox’s new approach.

dynamite-ready 6y ago

This is an aside, but to my mind, when necessary (when you're storing user data) devs should be transparent about how that data is stored. Websockets won't necessarily mean you avoid persisting state on the browser. In fact, you'll probably find you'll need to store some tokens on the client, somehow, just to secure the client/server connection.

mbreese 6y ago

> This is a red herring. ... that's a legal issue with the requirement to notify users they are being tracked It’s not a red herring. And it’s not the website warnings that are the issue, it’s the tracking that they have to notify you about. If we didn’t have to allow cookies for basic interactions with websites (like a session cookie), then we wouldn’t need to allow tracking cookies at all. However, because we need to allow session cookies, other sites can then track us. With a persistent connection/session, this wouldn’t be necessary. But clearly, there are many other ways to tackle this problem. And the persistent socket connection also has issues. But after thinking about this, I think the company behind the current dominant browser may be a little conflicted about solving this issue. I’m hopeful about Firefox’s new approach.