Re: Some half-baked thoughts about cookies.

On Wed, Aug 15, 2018 at 8:01 AM Daniel Stenberg <daniel@haxx.se> wrote:

> On Tue, 14 Aug 2018, Mike West wrote:
>
> > https://github.com/mikewest/http-state-tokens suggests that we should
> > introduce a client-controlled, origin-bound, HTTPS-only session
> identifier
> > for network-level state management. And eventually deprecate cookies.
>
> I'm thinking this suggestion will handle some cookie use cases really fine
> (login-like for example) but some others much less fine:
>
> Imagine a site that uses a cookie (for millions of users) if they saw the
> introduction page or not and can skip showing it if the user already saw
> it.
> Setting a cookie "sawintro=yes" is very lightweight and easy. Each client
> is
> then responsible for telling the server on the next visit that it already
> saw
> it; cookies used for client-side state as it was meant to be.
> Sec-HTTP-State
> doesn't make this very easy...
>

I agree that folks are using cookies for this kind of work today, and that
they're a very convenient way of outsourcing the responsibility for
maintaining state to the client. It's not clear to me that we should ask
clients to accept that obligation. In my opinion, the analysis of status
quo `Cookie` header length presented in
https://github.com/mikewest/http-state-tokens#a-problem is fairly damning
of the current setup, suggesting that servers are abusing the ability to
offload work to the client. It seems reasonable to me to ratchet down on
that ability over time, and to encourage server operators to take on both
the cost and responsibility.


> So, looking into the crystal ball, won't this lead to clients using both
> cookies *and* Sec-HTTP-State ?
>

For a (long) while, yes. There are specific use cases that this new thing
will server very well that can be quickly adopted. There are other use
cases that this new thing suggests should be done differently. Those will
take time to sort out. My goal here is to build a new thing to point folks
towards, which will allow us to impose restrictions on cookies over time
that will guide developers towards the new thing and away from the old
thing.


> Then, a suggestion on terminology: The document says "browser" in eight
> places
> when talking about a cookie-using HTTP client. Cookies is a well used
> mechanism even for non-browser HTTP clients and I believe referring to the
> user-agent as a "browser" in a document like this is bad.
>

Yes. That was myopic of me:
https://github.com/mikewest/http-state-tokens/commit/e577abc6baf18bedfc4ea6973e864eb0ca1ca363
.

-mike